Skip to content

docs(rfc): propose sandbox service exposure architecture - #4267

Open
drew wants to merge 10 commits into
mainfrom
codex/4266-sandbox-service-exposure-rfc
Open

drew wants to merge 10 commits into
mainfrom
codex/4266-sandbox-service-exposure-rfc

Conversation

@drew

@drew drew commented Oct 6, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

RFC 0017 proposes a dedicated application listener on supervisors so sandbox HTTP and WebSocket traffic can bypass the gateway and its control connection. This lets operators scale application ingress and configure its access policies separately from gateway management.

The gateway continues to manage service declarations and publishes supervisor-advertised routes through authenticated discovery. Operators can integrate existing ingress with that discovery or use the optional openshell-sandbox-proxy as a reference implementation.

Design

  • Make the supervisor app listener the core feature, with hostname routing to sandbox services under each sandbox's policy.
  • Support Kubernetes ingress plus a discovery adapter routing to supervisor Services.
  • Accommodate future shared supervisors while preserving distinct sandbox policies.
  • Preserve existing service commands and gateway routing for simple deployments.
  • Leave TLS termination, ingress policy, discovery authorization, and route lifecycle details open for review.

Validation

  • Repository Markdown lint passes.
  • Diff whitespace checks pass.
  • RFC-only change; no runtime implementation.

Related issue

Closes #4266

Related work

Signed-off-by: Drew Newberry <anewberry@nvidia.com>
@drew
drew requested review from mrunalp and sjenning as code owners October 6, 2026 23:35
@drew drew added the rfc label Oct 6, 2026
@drew
drew requested review from a team and derekwaynecarr as code owners October 6, 2026 23:35
@drew drew added the rfc label Oct 6, 2026
drew added 5 commits October 6, 2026 16:35
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
@TaylorMutch TaylorMutch self-assigned this Oct 7, 2026
@rrhubenov

rrhubenov commented Oct 8, 2026 •

Copy link
Copy Markdown
Contributor

Thank you for the doc, leaving some diagrams that might help with discussions:
Option 1
image
Option 2
image
Option 3
image

Discussed this with @kon-angelo and @dimityrmirchev, our opinion is that option 3 fits the best in a k8s environment specifically. Existing k8s clusters have their networking configured using k8s primitives, so having a proxy being created by OpenShell might not be desired by operators of the clusters on which it is deployed.

During a talk with @drew and @johntmyers, we came to the conclusion that Option 1 (the additional proxy component setup) can be implemented in such a way so that the proxy (and most likely the services) can be an optional component. This way, operators can decide easily between Option 1 and Option 3.

Signed-off-by: Taylor Mutch <taylormutch@gmail.com>
Signed-off-by: Taylor Mutch <taylormutch@gmail.com>
Signed-off-by: Taylor Mutch <taylormutch@gmail.com>
@TaylorMutch

Copy link
Copy Markdown
Collaborator

Picking this RFC up from @drew, I'll be pushing an update to this branch that includes the feedback from @rrhubenov and the community call.

Signed-off-by: Taylor Mutch <taylormutch@gmail.com>

This branch has not been deployed

No deployments
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.

docs(rfc): define sandbox service exposure architecture

3 participants