Skip to content

Sandboxes: published ports now default to IPv4 - #25868

Draft
robmry wants to merge 1 commit into
docker:mainfrom
robmry:sandboxes-tcp4-default
Draft

Sandboxes: published ports now default to IPv4#25868
robmry wants to merge 1 commit into
docker:mainfrom
robmry:sandboxes-tcp4-default

Conversation

@robmry

@robmry robmry commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

Description

Docker Sandboxes 0.39 publishes a port on IPv4 only when no protocol is named, where it previously bound both address families (docker/sandboxes#4994, reported as docker/sbx-releases#342). Three pages still describe the old behaviour, and one of them recommends a pattern that now works against the fix.

customize/kit-reference.md said an empty protocol means tcp, and its example spelled out protocol: tcp. Both are now misleading: omitting the field publishes IPv4 only, which is what a service bound to 0.0.0.0 needs, while tcp publishes both families and needs the service listening on IPv6 too. A kit copying the old example opts itself out of the new default — that is exactly what happened to the code-server kit (docker/sbx-kits-contrib#208). The field table now points at prose that explains both choices, and the example omits the field.

workflows.md told readers to work around dual-stack publishing themselves ("pin the published port to one family with --publish 8080:3000/tcp4"). The default now does that for them, so the paragraph explains what the default gives you and what naming tcp or /tcp6 requires instead.

workflows.md and usage.md both showed sbx ls reporting 127.0.0.1:8080->3000/tcp for a defaulted publish. It now reports /tcp4.

The CLI reference at data/sbx_cli/sbx_ports.yaml is generated from the sandboxes repo and already carries the new help text, so it needs a sync rather than an edit here. ai/sandboxes/release-notes.md is generated too, and picks the change up from the release's own notes.

Related issues or tickets

Reviews

  • Technical review
  • Editorial review
  • Product review

🤖 Raised by Claude Code on behalf of @robmry.

Docker Sandboxes 0.39 publishes a port on IPv4 only when no protocol is
named, where it previously bound both address families. That removes a
dead end: a dual-stack binding forwarded a host connection arriving on
::1 to the sandbox's IPv6 address, where a service listening only on
IPv4 never answered, and the connection was accepted and then reset —
which no client recovers from, unlike a refusal.

Three pages described the old behaviour:

- the kit reference said an empty `protocol` meant `tcp`, and its example
  spelled out `protocol: tcp`, which now opts a kit out of the default
  and back into the dead end;
- the workflows guide told readers to work around dual-stack publishing
  by pinning `/tcp4` themselves;
- both the workflows and usage pages showed `sbx ls` reporting `/tcp`
  for a defaulted publish.
@netlify

netlify Bot commented Aug 17, 2026

Copy link
Copy Markdown

Deploy Preview for docsdocker ready!

Name Link
🔨 Latest commit f5f26d3
🔍 Latest deploy log https://app.netlify.com/projects/docsdocker/deploys/6a82f60765dece0008d696b1
😎 Deploy Preview https://deploy-preview-25868--docsdocker.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@dvdksn

dvdksn commented Aug 27, 2026

Copy link
Copy Markdown
Contributor

Thanks for getting to this first, and sorry I missed this PR before opening #25949. Let’s use this as the canonical update.

Before merging, could you:

  • Rebase onto current main, where workflows.md moved to workflows/development.md
  • Add that an omitted protocol becomes tcp6 when an explicit IPv6 host IP is provided
  • Add that publishing a port starts a stopped local sandbox
  • Correct the PR description from v0.39 to v0.42

The kit example here correctly omits protocol: tcp, which #25949 missed and which is necessary for the port to inherit the IPv4-only default.

Generated by Codex

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants