publish updates from main (#22857)

Automated pull request for publishing docs updates.

---------

Signed-off-by: Craig <[email protected]>
Co-authored-by: Sarah Sanders <[email protected]>
Co-authored-by: Sebastiaan van Stijn <[email protected]>
Co-authored-by: Craig Osterhout <[email protected]>
Co-authored-by: Arthur <[email protected]>

Author: 4 people

.github/CODEOWNERS

@@ -29,12 +29,6 @@
 
 /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
@@ -44,3 +38,7 @@
 /content/manuals/ai/ @ArthurFlag
 
 /_vendor @sarahsanders-docker @ArthurFlag
+
+/content/manuals/cloud/ @craig-osterhout
+
+/content/manuals/dhi/ @craig-osterhout

.github/labeler.yml

@@ -50,6 +50,11 @@ area/build-cloud:
       - any-glob-to-any-file:
           - content/manuals/build-cloud/**
 
+area/cloud:
+  - changed-files:
+      - any-glob-to-any-file:
+          - content/manuals/cloud/**
+
 area/compose:
   - changed-files:
       - any-glob-to-any-file:
@@ -62,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:

assets/css/global.css

@@ -39,18 +39,6 @@ input[type="search"]::-moz-search-cancel-button {
 input[type="search"]::-ms-clear {
   display: none;
 }
-.prose {
-  code {
-    @apply !bg-gray-100;
-  }
-  & .highlight,
-  & :not(pre) > code {
-    .dark & {
-      background: var(--color-gray-900) !important;
-      border-color: var(--color-gray-700) !important;
-    }
-  }
-}
 
 .prose {
   li {

assets/css/syntax-dark.css

@@ -14,20 +14,15 @@
   /* LineHighlight */
   .hl {
     min-width: fit-content;
-    background-color: var(--color-gray-700);
-  }
-  .lntd:first-child .hl,
-  & > .chroma > code > .hl {
-    margin-left: -4px;
-    border-left: 4px solid var(--color-gray-900);
+    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-900);
+    color: var(--color-gray-300);
   }
   /* LineNumbers */
   .ln {

assets/css/syntax-light.css

@@ -14,12 +14,7 @@
   /* LineHighlight */
   .hl {
     min-width: fit-content;
-    background-color: var(--color-blue-100);
-  }
-  .lntd:first-child .hl,
-  & > .chroma > code > .hl {
-    margin-left: -4px;
-    border-left: 4px solid var(--color-blue-300);
+    background-color: var(--color-gray-100);
   }
   /* LineNumbersTable */
   .lnt {

assets/css/theme.css

@@ -200,4 +200,7 @@
   --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);
+
+  --tw-prose-code-bg: var(--color-gray-100);
+  --tw-prose-code-bg-dark: var(--color-gray-800);
 }

assets/css/utilities.css

@@ -153,7 +153,10 @@
   }
 
   :not(pre) > code {
-    background: var(--color-gray-200);
+    background: var(--tw-prose-code-bg);
+    .dark & {
+      background: var(--tw-prose-code-bg-dark);
+    }
     display: inline-block;
     margin: 0;
     font-weight: 400;

content/manuals/admin/company/users.md

@@ -12,4 +12,4 @@ You can manage users at the company-level in the Docker Admin Console.
 
 ## 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).
+Use Docker Hub to add a member to a team or remove a member from a team. For more details, see [Manage members](../organization/members.md#manage-members-on-a-team).

content/manuals/admin/organization/members.md

@@ -63,13 +63,23 @@ After inviting members, you can resend or remove invitations as needed.
 {{< tabs >}}
 {{< tab name="Admin Console" >}}
 
-To resend an invitation from the Admin Console:
+You can send individual invitations, or bulk invitations from the Admin Console.
+
+To resend an individual invitation:
 
 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**.
+3. Select the **action menu** next to the invitee and select **Resend**.
 4. Select **Invite** to confirm.
 
+To bulk resend invitations:
+
+1. In the [Admin Console](https://app.docker.com/admin), select your organization.
+2. Select **Members**.
+3. Use the **checkboxes** next to **Usernames** to bulk select users.
+4. Select **Resend invites**.
+5. Select **Resend** to confirm.
+
 {{< /tab >}}
 {{< tab name="Docker Hub" >}}
 

content/manuals/ai/model-runner/_index.md

@@ -93,7 +93,7 @@ Models are cached locally.
 {{< /tab >}}
 {{< tab name="From the Docker CLI">}}
 
-Use the [`docker model pull` command](/reference/cli/docker/).
+Use the [`docker model pull` command](/reference/cli/docker/model/pull/).
 
 {{< /tab >}}
 {{< /tabs >}}
@@ -109,7 +109,7 @@ The interactive chat screen opens.
 {{< /tab >}}
 {{< tab name="From the Docker CLI" >}}
 
-Use the [`docker model run` command](/reference/cli/docker/).
+Use the [`docker model run` command](/reference/cli/docker/model/run/).
 
 {{< /tab >}}
 {{< /tabs >}}
@@ -126,7 +126,7 @@ Select **Models** and select the **Logs** tab.
 {{< /tab >}}
 {{< tab name="From the Docker CLI">}}
 
-Use the [`docker model log` command](/reference/cli/docker/).
+Use the [`docker model logs` command](/reference/cli/docker/model/logs/).
 
 {{< /tab >}}
 {{< /tabs >}}

content/manuals/build-cloud/builder-settings.md

@@ -6,7 +6,9 @@ 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
+
+### Disk allocation
 
 The **Disk allocation** setting lets you control how much of the available
 storage is dedicated to the build cache. A lower allocation increases
@@ -29,11 +31,28 @@ Your subscription includes the following Build cache space:
 | Team         | 100GB             |
 | Business     | 200GB             |
 
-To get more Build cache space, [upgrade your subscription](/manuals/subscription/change.md).
+### 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/scale.md).
 
 > [!TIP]
 >
-> If you build 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
 
@@ -67,7 +86,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.

content/manuals/dhi/about/available.md

@@ -34,8 +34,8 @@ requirements:
   many language ecosystems and enterprise systems.
 
 - Alpine-based images: A smaller and more lightweight option using musl libc.
-  These images are faster to pull and have a reduced footprint, though you may
-  need to account for musl-glibc differences in some applications.
+  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.
@@ -52,8 +52,8 @@ with. Debian tends to offer the broadest compatibility.
 
 ## Development and runtime variants
 
-To accommodate different stages of the application lifecycle, DHI offers images
-in several 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

content/manuals/dhi/about/test.md

@@ -23,7 +23,7 @@ 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 and meet expected performance benchmarks.
+  function correctly.
 
 ## Image standards compliance
 
@@ -33,8 +33,8 @@ Each DHI undergoes rigorous checks to meet the following standards:
   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,
-  including `linux/amd64` and `linux/arm64`, to ensure broad compatibility.
+- 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.

content/manuals/dhi/about/what.md

@@ -77,17 +77,17 @@ so you don’t have to.
   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. You can choose between Alpine-based images (using musl libc) and
-  Debian-based images (using glibc) to suit your application's compatibility
-  requirements.
+  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 percent of the traditional container attack surface.
+- 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, 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.

content/manuals/dhi/how-to/mirror.md

@@ -158,6 +158,21 @@ $ docker push registry.example.com/my-project/<image>:<tag>
 > To continue receiving image updates and preserve access to Docker Hardened
 > Images, ensure that any copies pushed to other registries remain private.
 
+### Include attestations when mirroring images
+
+Docker Hardened Images are signed and include associated attestations that
+provide metadata such as build provenance and vulnerability scan results. These
+attestations are stored as OCI artifacts and are not included by default when
+using the Docker CLI to mirror images.
+
+To preserve the full security context when copying DHIs to another registry, you
+must explicitly include the attestations. One tool is `regctl`, which supports
+copying both images and their associated artifacts.
+
+For more details on how to use `regctl` to copy images and their associated
+artifacts, see the [regclient
+documentation](https://regclient.org/cli/regctl/image/copy/).
+
 ## What's next
 
 After mirroring an image repository, you can you can start [using the

layouts/shortcodes/admin-users.html

@@ -125,6 +125,25 @@
 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.
 
+### Resend invitations to users
+
+You can send individual invitations, or bulk invitations from the Admin Console.
+
+To resend an individual invitation:
+
+1. In the [Admin Console](https://app.docker.com/admin), select your company.
+2. Select **Users**.
+3. Select the **action menu** next to the invitee and select **Resend**.
+4. Select **Invite** to confirm.
+
+To bulk resend invitations:
+
+1. In the [Admin Console](https://app.docker.com/admin), select your company.
+2. Select **Users**.
+3. Use the **checkboxes** next to **Usernames** to bulk select users.
+4. Select **Resend invites**.
+5. Select **Resend** to confirm.
+
 ### Invite members via API
 
 You can bulk invite members using the Docker Hub API. For more information, see