## Summary
Refresh the vendored Sandboxes cookbook and OpenAPI reference from
upstream.
Removes standalone MCP gateway start/stop documentation, imports
upstream authentication and timeout examples, auto-resume readback
guidance, and network-policy selector updates, and regenerates the API
presentation data.
@netlify /ai/sandboxes-api/cookbook/give-a-sandbox-an-mcp-gateway/
Generated by Codex
API generation introduced in #26048 added roughly five minutes to site
builds: median successful main-branch build-workflow duration rose from
4m 05s to 8m 48s across September 3–25. The pre-build command took 4m
41s–4m 53s in each of four jobs on the merge commit.
Vendor the generated presentation model in `data/api-reference.json`,
mark it as generated, and let Docker, Netlify, and local Hugo builds
consume it directly. Keep the existing rendered-output checks.
Move generator tests, strict spec validation, and a byte-for-byte
regeneration check into `docker buildx bake validate-api-reference`,
inheriting the shared Docker base stage. The target uses the pinned
Vacuum release binary with Dockerfile ADD checksum verification and
archive extraction instead of compiling Vacuum from source. The existing
build workflow runs this target alongside the other validation matrix
entries. Only this matrix entry is advisory; its failures do not block
site builds or deployment.
Validated locally with the Docker target, rejection of deliberately
stale data, repeatable generation across directories, a production Hugo
build and verification of 453 API HTML/Markdown page pairs, workflow
syntax checks, and scoped documentation lint. The prebuilt-binary CI
check passed in 1m 40s, down from 5m 15s with source compilation. Remote
layer-cache settings were subsequently removed; local Go cache mounts
remain.
Generated by Codex
## Description
Add an experimental Sandboxes API and SDK section alongside Docker
Sandboxes under AI and agents, at `/ai/sandboxes-api/`. Cover
installation of `@docker/sandboxes`, browser and PAT authentication, and
a TypeScript walkthrough that launches the shell kit, runs a command,
and deletes the sandbox. Explain kits and image choices with examples,
along with compute sizes, quotas, permissions, resource lifecycle,
errors, and retries. Link subscription setup and billing to the shared
Docker Agentic Platform guide. Preserve the previous
`/ai/sandboxes/api/` URLs with redirects.
Uses the shared Docker Agentic Platform documentation merged in #26142.
Sibling to #26158, which introduces CLI-side Cloud Sandboxes
documentation.
Include 36 SDK cookbook recipes at `/ai/sandboxes-api/cookbook/` and the
public REST API reference at `/reference/api/sandboxes/`. Import the
generated export from `docker/sbx-api` commit `60d79c1d` (source
`1a7f4026`). Overview and installation remain maintained here. The
reference uses the shared API renderer from main, with separate
operation and schema pages, streaming and WebSocket details, and a
downloadable OpenAPI spec. An API reference link appears in the API/SDK
sidebar. A pinned manifest and import script provide the basis for later
release automation.
Examples are optional in the shared renderer; supplied examples still
have to pass schema validation. Requests without body examples use a
request-body file with instructions to prepare it. The import copies all
selected recipes and the OpenAPI specification byte for byte from the
corrected upstream export, without patches or link rewrites. The broken
naming recipe remains temporarily excluded.
This remains a draft pending validation against the published npm SDK.
The imported cookbook contains the TypeScript-only guidance, five-minute
request deadlines, kit-readiness explanation, active-policy status
requirement, and snapshot-deletion and lifetime-renewal restrictions.
Validation: scoped Markdown and Vale checks, full Hugo build, rendered
navigation, redirects, and internal links, and TypeScript type-checking
against the generated public SDK from `docker/sbx-api` commit
`68f214b9`. Import validation also covers all 60 REST operations and 188
schema definitions, 1,198 imported-page links and anchors,
desktop/mobile rendering, Markdown output, spec delivery, and a repeat
import. The shared renderer tests, strict generation for all five APIs
(zero diagnostics), full Hugo build, and verification of 453
HTML/Markdown page pairs and API links pass. No live sandbox execution.
The corrected export passes strict generation for all five APIs with
zero diagnostics, scoped Markdown/Vale lint, a full Hugo build, and
verification of 453 HTML/Markdown page pairs and API links. A repeat
import produces identical files. The spec update changes examples only;
schemas and operations are unchanged.
@netlify /ai/sandboxes-api/
Generated by Codex
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Summary
Vendor the OpenAPI 3.2 specification merged in
docker/governor-services#755 and move AI Governance onto the unified API
reference renderer while preserving its existing URLs. This supersedes
#26067, which vendors an earlier upstream revision and retains the
legacy renderer.
@netlify /reference/api/ai-governance/latest/
[Deploy
preview](https://deploy-preview-26125--docsdocker.netlify.app/reference/api/ai-governance/latest/)
Generated by Codex
@netlify /reference/api/
[Preview the API
reference](https://deploy-preview-26048--docsdocker.netlify.app/reference/api/)
Adds a shared API reference experience for Hub, DVP, and Registry: a
catalog, operation navigation, linked schemas, request and response
examples, and matching HTML and Markdown output. A validation and
generation pipeline prepares the reference data for Hugo and runs as
part of Docker and Netlify builds.
Migrates the three specifications to OpenAPI 3.2, correcting response
shapes, nullable fields, and authentication and token examples. The Hub
migration also corrects SCIM contracts and CSV exports; DVP gains
complete report response schemas and examples. Registry keeps its
documented Hub-specific subset, with authentication and media
negotiation expressed through OpenAPI security and content fields.
Validation is strict for both checks and generation, with no exception
baseline or bypass flag. The build uses the migrated sources directly,
without migration scripts or records.
Page and specification URLs remain stable, including the DVP alias.
Operation and schema anchors change. Engine and Governance retain their
existing references.
Validated locally with Go tests, strict validation of all three
specifications (zero diagnostics), scoped formatting and lint, and a
full Hugo build checking all 176 HTML/Markdown page pairs, example
parity, reference links, and byte-identical published specifications. A
browser check confirmed raw CSV rendering and the generated request
header. No live API requests were made.
# To dos
~- Evaluate _index pages and standardize across account + admins
category~
~- Edit weights of topics~
- Notify TSEs, other stakeholders
- TW sign off
## Summary
This PR restructures the Platform documentation into a clearer Accounts,
Security, and Subscription and billing information architecture, with
aliases so existing URLs keep working.
Work from these PRs was merged into this feature branch:
- #25957 (Security IA)
- #25960 (Accounts and Admin)
- #25981 (Subscription and billing)
### Accounts
- Moves organization, company, and admin content under Accounts.
- Splits individual-account docs into their own subsection.
- Removes the standalone Admin section; those pages now live under
Accounts.
### Security
- Publishes Security at `/security/`, matching other Platform sections.
- Groups authentication (SSO, 2FA, OIDC), access tokens, provisioning,
and roles under Security.
- Leaves Enterprise Hardened Desktop and related enterprise security
docs under Enterprise.
- Restores shipped Hardened Desktop and security FAQ URLs so they match
`main`.
### Subscription and billing
- Merges Subscription and Billing into a single Subscription and billing
section.
- Drops the extra subcategory wrappers and nests billing tasks under
Manage.
- Shortens the billing details sidebar label.
### FAQs
- Consolidates Platform FAQs onto four pages: Accounts, Security,
Subscription and billing, and Platform.
- Folds leftover general, container, and network/VM security FAQs into
Platform FAQs.
- Folds SSO enforcement FAQs into the SSO FAQ.
- Templates FAQ pages with H2 topics and H3 questions, and limits the
table of contents to H2.
### Navigation and follow-ups
- Renames the manuals sidebar group from Platform to Accounts and admin,
and updates the manuals landing heading and copy to match.
- Fixes the MSI install Settings Management link after the security path
move.
- Updates CODEOWNERS, the labeler, and in-repo links to the new paths.
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
## Summary
- Document that member `PUT` `role` accepts a custom role **name**, not
only `owner` | `editor` | `member`.
- Document `role` on team `PATCH` (core or custom role name) and on
`org_group` so the PATCH 200 can include the assigned role.
- Add `Editor` to `org_member.role` (title case). Live responses already
return it; the old enum was Owner / Member / Invitee only.
## Test plan
PM must confirm before merge:
- [ ] Member PUT 200: after assigning a custom role (body is not the
previous core role), is `role` still a core value (`Owner` / `Editor` /
`Member`), or is it the custom role **name**? If it is the custom name,
drop the `org_member.role` enum in a follow-up and describe a string
(core or custom name). If it stays a core value, this PR's enum (`Owner`
| `Editor` | `Member` | `Invitee`) is enough.
- [ ] List members: same field. Confirm a user with a custom role lists
as a core value vs the custom name.
- [ ] Casing: request stays lowercase (`editor`); response stays title
case (`Editor`). Confirm that split is real.
- [ ] Team PATCH 200: confirm `org_group.role` is present and is the
value just set (core or custom name).
- [ ] Team assignment is PATCH-only, not PUT.
- [ ] Unknown role names return an error; do not document them as valid.
- [ ] Custom role **name** (not label or UUID) is the request
identifier, matching Docker Home.
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
## Summary
Documents which Docker Hub API endpoints accept org access token (OAT)
authentication, and the scope-dependent listing behavior for repository
listing.
### Changes
- **`content/reference/api/hub/latest.yaml`**: Added `<span
class="oat"></span>` markers to 11 repository endpoint groups under
`/v2/namespaces/{namespace}/repositories/`. Includes a note on
scope-based listing behavior for `GET
/v2/namespaces/{namespace}/repositories`.
- **`content/manuals/enterprise/security/access-tokens.md`**: New "Hub
API support" section covering supported endpoint categories and the
`scope-repository-list` listing behavior.
### OAT listing behavior
`GET /v2/namespaces/{namespace}/repositories`:
- OAT **with** `scope-repository-list` → returns all repos including
private
- OAT **without** that scope → returns only public repos
## Test plan
- [ ] Preview site renders `<span class="oat">` badge on repo endpoints
- [ ] Hub API support section appears correctly in access-tokens manual
page
- [ ] Listing behavior note is clear and accurate
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Alexa Kristensen <81787716+akristen@users.noreply.github.com>
## Summary
- Adds OpenAPI 3.0 spec and API reference page for the Docker Enterprise
Data API at `/reference/api/enterprise-data/`
- Adds feature guide for enterprise usage reports at
`/manuals/enterprise/reports/`
## Context
Docker Enterprise subscribers will be able to programmatically export
organization usage reports (pull data) via
`api.docker.com/enterprise-data/v1/`. This is a new API surface,
separate from the Hub API, supporting both PAT and OAT authentication.
Related PRs:
- API implementation:
[docker/data-platform#817](https://github.com/docker/data-platform/pull/817)
- FGA scope for OAT auth:
[docker/iam-services#1029](https://github.com/docker/iam-services/pull/1029)
## New pages
| Path | Description |
|---|---|
| `/reference/api/enterprise-data/api.yaml` | OpenAPI 3.0 spec (4
endpoints: list types, list reports, download, schema) |
| `/reference/api/enterprise-data/index.md` | API reference landing page
|
| `/manuals/enterprise/reports/_index.md` | Feature guide with auth
setup, curl walkthrough, pagination, troubleshooting |
## Test plan
- [ ] API reference renders correctly at
`/reference/api/enterprise-data/`
- [ ] Feature guide renders in the Enterprise sidebar
- [ ] curl examples are copy-pasteable and accurate
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: Alexa <alexa.kristensen@docker.com>
Sync the AI Governance Policy API reference with the upstream spec from
docker/governor-services. Renames the shared 403 response component from
PermissionDenied to Forbidden across the policy/rule endpoints, and adds a
limit_exceeded error code covering org policy and per-policy rule maximums.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
Sync the AI Governance Policy API reference with the upstream spec from
docker/governor-services#242. Wraps the ListPolicies response data under
a `data` object, adds the updatePolicy and deletePolicy endpoints,
migrates policy scope from profiles to teams, and switches rule/policy
updates to application/json.
Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
## Summary
Restructures the Docker AI Governance documentation under
\`/ai/sandboxes/governance/\` and adds the supporting API reference.
Preview links:
-
https://deploy-preview-25162--docsdocker.netlify.app/ai/sandboxes/governance/
-
https://deploy-preview-25162--docsdocker.netlify.app/reference/api/ai-governance/
### Information architecture
The existing \`security/governance\` and \`security/policy\` pages are
merged into a new top-level \`governance\` section so local-policy and
org-policy sit side by side instead of being split across unrelated
parents:
- \`/ai/sandboxes/governance/\` — section landing; explains local + org
as layered enforcement
- \`/ai/sandboxes/governance/concepts/\` — resource model, rule syntax,
evaluation, precedence
- \`/ai/sandboxes/governance/local/\` — \`sbx policy\` CLI for
individual machines
- \`/ai/sandboxes/governance/org/\` — Admin Console flow (was
\`security/governance.md\`)
- \`/ai/sandboxes/governance/monitoring/\` — \`sbx policy ls\` / \`sbx
policy log\`
### API reference
\`/reference/api/ai-governance/\` renders the Governance OpenAPI spec
vendored at \`content/reference/api/ai-governance/api.yaml\` from
\`docker/governor-services\`. Operations, schemas, examples, and status
codes are fully driven by the spec — future updates land via re-vendor,
not in-repo edits. Anything wrong in the rendered reference should be
fixed upstream and re-vendored here.
The spec has been re-vendored to the latest upstream version, which
updated the server URL to \`hub.docker.com/v2\` and added the
\`/governance/\` prefix to all API paths.
### Review focus
1. The \`/ai/sandboxes/governance/\` landing — does the local + org
framing match how the product is positioned?
2. \`/reference/api/ai-governance/\` — does the rendered spec match the
source of truth, and is anything important missing?
Generated by Claude Code
---------
Co-authored-by: Louis-Arnaud <la.catoire@gmail.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
PR to capture work:
- Update / simplify titles to match docs
- Create subcategories within org/company
- Wrestle with redirect nightmare part 2
Filing a follow up PR to create parallel structure in the `Company`
subcategory. This PR's scope is for `Organization` only.
Fixes discrepancies in the Docker Hub organization access token API
documentation to match actual API behavior.
Changes:
- Removed `created_by` field from create endpoint response (API only
returns `created_at`)
- Updated scope examples from `repo-pull` to `scope-image-pull` (correct
format with `scope-` prefix)
- Enhanced repository path documentation with validation requirements
for TYPE_REPO resources
These changes align the OpenAPI specification with the actual API
implementation as discovered during Terraform provider development.
Fixes#24406
---------
Co-authored-by: David Karlsson <dvdksn@users.noreply.github.com>
## Description
In order to better attribute upgrade sources, we are adding two params -
`ref` and `refAction` to the existing pricing url.
The `ref` will be "Docs" and the `refAction` will be the particular docs
page from where the pricing url click is originated.
## Related issues or tickets
https://docker.atlassian.net/browse/GRO-282
## Reviews
@akristen You should see the new url params when hovering over or
clicking any of the updated pricing urls
- [ ] Technical review
- [ ] Editorial review
- [ ] Product review
---------
Co-authored-by: Alexa Kristensen <81787716+akristen@users.noreply.github.com>
I noticed that building the examples would produce a client with the
default ("Go-http-client/1.1") User-Agent; this is something to look
into (probably should have a saner default), but regardless, it's
good practice to set your own;
- Update examples to show setting the User-Agent
- Use "log.Fatal" instead of "panic"; both exit the binary, but
probably are slightly more readable.
- Use the authconfig.Encode utility, which codifies the canonical
format to encode the JSON, so that users don't have to replicate
the same format.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
<!--Delete sections as needed -->
## Description
Delete operation may time-out. Hub automatically retries without user
interaction in both the UI and API.
Added notes to make the user aware.
## Related issues or tickets
ENGDOCS-3173
## Reviews
<!-- Notes for reviewers here -->
<!-- List applicable reviews (optionally @tag reviewers) -->
- [ ] Technical review
- [ ] Editorial review
- [ ] Product review
---------
Signed-off-by: Craig Osterhout <craig.osterhout@docker.com>
## Summary
Added documentation for DOCKER_HOST requirement when using Docker SDKs
with Docker Desktop for Linux.
## Changes
- Added "Using Docker SDKs with Docker Desktop" section to Linux install
docs explaining why SDKs need DOCKER_HOST set and providing
configuration commands
- Added FAQ entry "How do I use Docker SDKs with Docker Desktop for
Linux?" with troubleshooting steps
- Added note in SDK reference docs alerting Docker Desktop for Linux
users to set DOCKER_HOST before using SDKs
Fixes#23308
---
🤖 Generated with [cagent](https://github.com/docker/cagent)
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: aevesdocker <allie.sadler@docker.com>
<!--Delete sections as needed -->
## Description
Adds the Offload activity log events to the activity-logs documentation.
Adds all activity log actions to the audit-logs API spec.
## Related issues or tickets
<!-- Related issues, pull requests, or Jira tickets -->
## Reviews
<!-- Notes for reviewers here -->
<!-- List applicable reviews (optionally @tag reviewers) -->
- [ ] Technical review
- [ ] Editorial review
- [ ] Product review
---------
Signed-off-by: Nick Adcock <nick.adcock@docker.com>
