Hi, and thanks for the project.
We are evaluating Open-Inspect as a self-hosted background coding-agent platform on an internal Kubernetes (AKS) cluster, where a hard requirement is that no third-party sandbox service receives source code. Before investing further we would like to know whether a Kubernetes sandbox provider contribution would be welcome upstream, or whether you would prefer it stays a downstream fork.
Intended design (deliberately minimal, mirroring e2b-provider.ts):
- New
packages/control-plane/src/sandbox/providers/kubernetes-provider.ts, registered in provider-name.ts / provider-factory.ts as SANDBOX_PROVIDER=kubernetes.
- One Pod per sandbox from a configurable sandbox image, running the existing
sandbox_runtime.entrypoint as a non-root user (drop ALL caps, seccomp RuntimeDefault, no SA token), plus a per-sandbox PVC for the workspace and a per-sandbox Secret carrying the env built by buildSandboxEnvVars.
- Readiness stays the existing contract (the bridge phones home); the provider only waits for the Pod to reach Running before returning.
- Capabilities:
supportsSandboxTimeout (activeDeadlineSeconds), supportsExplicitStop and supportsPersistentResume (stop deletes the Pod and keeps the PVC; resume recreates the Pod on it). supportsSnapshots / supportsRestore false initially; no image builds initially.
- Kubernetes API access through
@kubernetes/client-node behind a small injectable interface so unit tests use a fake, as the E2B tests do. Namespace, image, resources, storage class, UID and an optional CA-bundle ConfigMap come from env, documented in .env.example.
- Code-server / VNC / tunnel URLs would be unsupported at first (they need per-pod ingress).
We have a working draft of roughly 2k lines including tests. If this fits your roadmap we would clean it up into a PR; if not, no hard feelings, we would just like to know before we shape it for upstream review. Any constraints you would want respected (file layout, capability choices, avoiding the node-only dependency in the Worker bundle, which we currently mark external) are very welcome.
Hi, and thanks for the project.
We are evaluating Open-Inspect as a self-hosted background coding-agent platform on an internal Kubernetes (AKS) cluster, where a hard requirement is that no third-party sandbox service receives source code. Before investing further we would like to know whether a Kubernetes sandbox provider contribution would be welcome upstream, or whether you would prefer it stays a downstream fork.
Intended design (deliberately minimal, mirroring
e2b-provider.ts):packages/control-plane/src/sandbox/providers/kubernetes-provider.ts, registered inprovider-name.ts/provider-factory.tsasSANDBOX_PROVIDER=kubernetes.sandbox_runtime.entrypointas a non-root user (drop ALL caps, seccomp RuntimeDefault, no SA token), plus a per-sandbox PVC for the workspace and a per-sandbox Secret carrying the env built bybuildSandboxEnvVars.supportsSandboxTimeout(activeDeadlineSeconds),supportsExplicitStopandsupportsPersistentResume(stop deletes the Pod and keeps the PVC; resume recreates the Pod on it).supportsSnapshots/supportsRestorefalse initially; no image builds initially.@kubernetes/client-nodebehind a small injectable interface so unit tests use a fake, as the E2B tests do. Namespace, image, resources, storage class, UID and an optional CA-bundle ConfigMap come from env, documented in.env.example.We have a working draft of roughly 2k lines including tests. If this fits your roadmap we would clean it up into a PR; if not, no hard feelings, we would just like to know before we shape it for upstream review. Any constraints you would want respected (file layout, capability choices, avoiding the node-only dependency in the Worker bundle, which we currently mark external) are very welcome.