The agent.persistence field was removed from kits, so drop it from the
spec reference, the agent block examples, and the build-an-agent tutorial.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The links pointed to #defining-an-agent, but the heading "Define an
agent" slugifies to #define-an-agent.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Move the spec.yaml field reference out of the Kits overview page into a
new Kit spec reference page, keeping the overview focused on concepts and
usage. Rewire cross-page links accordingly.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
<!--Delete sections as needed -->
## Description
Updated intro and the section for find.
The Helm docs link is removed as users on this page are expected to know
what a Helm chart is, and "Docker-provided" immediately before it makes
the link misleading. The Find section is no longer needed as the catalog
can be linked directly and viewed without signing in.
Preview:
https://deploy-preview-25334--docsdocker.netlify.app/dhi/how-to/helm/
## Related issues or tickets
https://docker.slack.com/archives/C04300R4G5U/p1781196686143879
## Reviews
<!-- Notes for reviewers here -->
<!-- List applicable reviews (optionally @tag reviewers) -->
- [ ] Editorial review
Signed-off-by: Craig Osterhout <craig.osterhout@docker.com>
<!--Delete sections as needed -->
## Description
Refreshed Node.js guide
- Updated all examples to DHI. DHI Community is now free so the DOI
fallback is no longer needed.
- Replaced the git clone pattern with the file scaffolding component.
- Simplified the sample app to a Node.js backend API. Added links at the
start of the guide to dedicated frontend framework guides.
- Added "Secure your Node.js image supply chain" topic to showcase DHI.
- Refreshed topic intros and related links.
https://deploy-preview-25319--docsdocker.netlify.app/guides/nodejs/
## Related issues or tickets
ENGDOCS-3319
Closes#25280
## 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>
Three small fixes in the guides.
- `guides/localstack`: the prose says `S3_ENDPOINT_URL` is
`http://localhost:4556`, but LocalStack's edge port is `4566`, and the
guide's own `.env` block later uses `4566`.
- `guides/pgadmin`: the top-level Compose key for the pgpass file is
`configs`, not `config`. As written the compose file is invalid.
- `guides/bun/deploy`: the "Turn on Kubernetes" link has a doubled slash
(`/manuals//desktop/...`).
Signed-off-by: Emmanuel Yusufu Kimaswa <kimaswaemma36@gmail.com>
The `/docker-entrypoint-initaws.d` directory was removed in LocalStack
2.0. Updates the Compose snippet to mount the current `ready.d` init
hook directory and adds a short tip pointing to the LocalStack init
hooks reference. Also drops a stray trailing quote that made the
previous mount path invalid.
Closes#22640
## Description
The prerequisites section for deactivating a Docker account contained a
broken bullet:
> Unlink your [GitHub and account](...)
\"GitHub and account\" is not grammatical. The linked page covers
unlinking both GitHub and Bitbucket accounts (for the deprecated
automated builds feature), but only GitHub was mentioned.
This fix:
- Rewrites the bullet to be grammatically correct
- Clarifies it only applies to users who linked accounts for automated
builds
- Adds a link for Bitbucket alongside GitHub
## Related issues or tickets
Fixes#25128
## Reviews
- [ ] Technical review
- [ ] Editorial review
Reorder the Docker registry section so it opens with the fact that
Docker Hub needs no registry credentials (sbx reuses your sbx login
session), then covers configuring credentials for other registries.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The Shell page had "Default startup command" as an h3 with no parent h2,
skipping a heading level. Promote it to h2 so it sits alongside "Base
image", consistent with the other agent pages.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
"The templates ... already includes uv" -> "include"; spell out "etc"
as "and so on".
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
"seamless" is on the repo's banned hedge-word list. State plainly that a
Docker account authenticates the requests.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Clone-mode sandboxes enable virtiofs caching automatically as of v0.32.0,
so note that the DOCKER_SANDBOXES_ENABLE_VIRTIOFS_CACHE tuning is only
relevant for direct-mode workspaces.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Compose, Engine, Desktop, and Docker Agent pages live on docs.docker.com,
so link to them with source-relative /manuals/ paths instead of absolute
https://docs.docker.com URLs. This matches the dominant convention in the
repo and lets Hugo resolve and link-check the references.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
commands.startup[].background now keeps a service alive and replays on
every container start (sbx-releases #2842, shipped in v0.30.0), so the
nohup/& shell workaround is no longer required. Lead the background
service example with background: true, drop the stale claim that the
field alone leaves the service attached to an exiting shell, and remove
the resolved follow-up TODO comment. Update the generic startup example
in the kits reference to match.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The --branch flag was removed in sbx v0.31.0 in favor of --clone. Drop
the troubleshooting section about stale host worktrees (clone mode keeps
no host-side worktree, so the scenario can no longer occur) and update
the architecture lifecycle note to describe clone-mode cleanup, which
removes the sandbox-<name> Git remote on sbx rm.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Two pages linked to usage.md#signed-commits, an anchor that does not
exist. The commit-signing content lives in workflows.md under the
"Commit signing" heading. Point both links there.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.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>
## Summary
`sbx` now prompts you to authenticate to Codex on the host before
launching the sandbox when no OpenAI credential is stored. Updated the
Codex agent page and the credentials best practices to describe this
flow, and reordered the Codex auth methods so OAuth (the host-side
prompted flow) leads.
Generated by Claude Code
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Inactive rules are now hidden by default when org governance is active.
Document the --include-inactive flag in the monitoring page and point the
concepts, local, and org policy pages to it instead of each restating the
display behavior.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
sbx now prompts you to authenticate to Codex on the host before launching
the sandbox when no OpenAI credential is stored. Update the Codex agent
page and the credentials best practices to describe this flow.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
## Summary
On Linux hosts without a running Secret Service (headless servers, some
WSL setups), `sbx` falls back to an encrypted on-disk store instead of
the OS keychain. This documents where secrets are stored per platform in
the credentials page and adds a headless-Linux FAQ entry.
> [!NOTE]
> This documents behavior from the unreleased PR
[docker/sandboxes#3231](https://github.com/docker/sandboxes/pull/3231).
Hold merge until that change ships. Opened as a draft for that reason.
## Learnings
- Origin of this change is a Slack thread, not a GitHub issue, so
there's no `Closes #` linkage.
Generated by Claude Code
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
## Summary
Adds `sbx secret set -g openrouter` and `OPENROUTER_API_KEY` to the
Authentication sections of `docker-agent.md` and `opencode.md`, matching
the OpenRouter support added in docker/sandboxes#3244. Also corrects the
Google env var in `opencode.md` from `GOOGLE_API_KEY` to
`GOOGLE_GENERATIVE_AI_API_KEY`, which is the name OpenCode actually
uses.
Closes#25273
Generated by Claude Code
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Summary
Adds an admin-facing guide for Docker Sandboxes organization sign-in
enforcement: admins deploy an enforcement configuration via endpoint
management (macOS configuration profile, Windows registry, Linux
root-owned JSON file) specifying allowed Docker Hub org slugs, and `sbx
login` verifies membership and revokes credentials on failure.
New page
`content/manuals/ai/sandboxes/governance/sign-in-enforcement.md` covers
how it works (login-time-only, fail-closed, auto-login behavior), the
configuration schema, per-platform deployment, and error messages. Also
cross-links from the governance overview and generalizes the security
page's organization-control section so it makes a single point about
admin-level controls rather than enumerating each feature.
## Learnings
- The `sbx` sign-in enforcement config is entirely endpoint/file-based
(`com.docker.sbx` managed prefs, `HKLM\SOFTWARE\Policies\Docker\SBX`,
`/etc/docker-sbx/config.json`) with no Admin Console UI — distinct from
sandbox org *policy* (network/filesystem), which is Admin Console + API
driven. Worth keeping these two admin mechanisms separate in the docs.
Generated by Claude Code
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Reframe the Docker registry section in sandbox workflows around pulling
private images (including templates) and pushing built images, reword
"store credentials on your host" to configuring credentials for sbx, and
cross-reference credentials.md for secret-type details instead of
duplicating them.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Added note about proxy configuration requirements for Docker Desktop.
<!--Delete sections as needed -->
## Description
<!-- Tell us what you did and why -->
Proxy configuration is a special case that needs configuration in Admin
Console as well as in admin-settings.json/install-settings.json. Most
customers miss the proxy configuration in
admin-settings/install-settings.json resulting in sign-in issues with
DD. Hopefully this will reduce the cases or at least we can point them
to this updated manual.
## Related issues or tickets
https://docker.atlassian.net/browse/SEG-1703
<!-- Related issues, pull requests, or Jira tickets -->
## Reviews
<!-- Notes for reviewers here -->
<!-- List applicable reviews (optionally @tag reviewers) -->
- [ ] Technical review
- [ ] Editorial review
- [ ] Product review
---------
Co-authored-by: Allie Sadler <102604716+aevesdocker@users.noreply.github.com>
## Description
- make the VEX prerequisites method-specific instead of implying every
workflow needs the containerd image store and registry write access
- reinforce the attestation-only requirements in the attestation section
## Related issues or tickets
- Addresses #24900
## Reviews
- [x] Technical review
- [ ] Editorial review
- [ ] Product review
<!--Delete sections as needed -->
## Description
Updated Python guide
- Removed DOI in favor of DHI only. DHI Community is now free, so
there's no reason to keep the DOI fallback path.
- Removed the git clone sample-app pattern. Maintaining external sample
repos is a burden, and split source of truth between the docs and the
sample.
- New file browser / scaffolding component. Lets users copy individual
files or scaffold the whole project with one command. Replaces the role
the cloned sample repo used to play.
- New "Secure your supply chain" topic highlighting what DHI gives you
and how to attach matching attestations to your own image in CI.
- A bunch of smaller improvements: clearer intros for each topic,
progressively updating the same app in all topics, ran and fixed issues,
etc.
https://deploy-preview-25206--docsdocker.netlify.app/guides/python/
## Related issues or tickets
ENGDOCS-3308
## Reviews
<!-- Notes for reviewers here -->
<!-- List applicable reviews (optionally @tag reviewers) -->
- [ ] Technical review
- [ ] Editorial review
---------
Signed-off-by: Craig Osterhout <craig.osterhout@docker.com>
## Description
Fixes a grammatical error in the Scout Slack integration page. The
phrase \"is not by a newly disclosed CVE\" is broken — it should read
\"is not affected by a newly disclosed CVE\", which is also consistent
with the same explanation in the dashboard documentation.
## Related issues or tickets
Fixes#25158
## Reviews
- [ ] Technical review
- [ ] Editorial review
<!--Delete sections as needed -->
## Description
Added VEX walkthrough guide for Docker Hardened Images
The existing DHI documentation covers VEX concepts and scanner
integration, but as separate reference topics. Users who want to
understand VEX in practice have to piece together the workflow
themselves.
This guide shows the full workflow end-to-end against a real image
(`dhi.io/python:3.13`): scan without VEX to get the raw CVE baseline,
fetch the attestation, scan again with VEX applied, then inspect every
suppression and the reasoning behind it. Each step shows actual command
output so readers can compare what they see against a known reference.
The guide covers:
- Before/after scans with Trivy and Grype to make the VEX effect
concrete
- Docker Scout's automatic VEX integration as a contrast
- Trivy's `--show-suppressed` flag to surface per-CVE justification
codes
- `jq` queries against the raw VEX file to read Docker's human-readable
reasoning and filter by status (`not_affected`, `under_investigation`,
`affected`)
The goal is to give readers a working mental model of what VEX does and
how to audit it — something a walkthrough can do that reference docs
can't.
https://deploy-preview-24992--docsdocker.netlify.app/guides/dhi-vex-walkthrough/
## Related issues or tickets
ENGDOCS-3239
## Reviews
<!-- Notes for reviewers here -->
<!-- List applicable reviews (optionally @tag reviewers) -->
- [ ] Editorial review
---------
Signed-off-by: Craig Osterhout <craig.osterhout@docker.com>
<!--Delete sections as needed -->
## Description
<!-- Tell us what you did and why -->
## 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: aevesdocker <allie.sadler@docker.com>
<!--Delete sections as needed -->
## Description
<!-- Tell us what you did and why -->
## 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: aevesdocker <allie.sadler@docker.com>
David Karlsson