Sharing the Sandboxes JuiceFS CSI driver across multiple LangSmith Helm releases
Last updated: September 3, 2026
Description
It is possible to run multiple LangSmith Helm releases on the same Kubernetes cluster, and have them share the Sandbox install.
Symptom
There are more than one self-hosted LangSmith Helm releases in the same Kubernetes cluster (for example, separate namespaces or environments). Sandboxes is already enabled on the first release with csi.install: true, which installs the JuiceFS CSI driver. It is possible to enable Sandboxes on a second release too, and the chart's guidance says only one release per cluster should install and manage the CSI driver.
The second release can enable Sandboxes with csi.install: false and share the driver from the first release, but there are details to be tweaked, such as knowing which values need to be overridden to avoid collisions, what ServiceAccount/IRSA role the second release's mount pods use, and whether two releases' sandbox-host pods can share a node.
Cause
Only the "installing" release (the one with csi.install: true) renders the CSI driver's node RBAC and generates secret names scoped to its own namespace and values. A second release configured with csi.install: false runs in "external driver" mode: it consumes the driver installed by the first release instead of installing its own. In this mode the chart doesn't grant the mount service account for the second release automatically, so its mount pods run under the installing release's ServiceAccount and IRSA role. That's expected (as default charts expect a single release), but it means the second release has no RBAC of its own granting access to the shared driver's secrets, so those have to be added that manually.
Separately, the sandbox-host pod uses host networking and binds a fixed container port on the host node, with a pod anti-affinity rule enforcing one sandbox-host pod per node. If two releases' sandbox-host pods land on the same node, the port collides. Each Sandboxes-enabled release currently needs its own dedicated sandbox-host node(s).
Release process
Enabling Sandboxes on a second release with csi.install: false is supported, sharing the JuiceFS CSI driver installed by the first release. To make it work, set the following on the second release:
csi.pvNameandcsi.pvcName: distinct values so the second release doesn't collide with the first release's PV/PVC objects when sharing the same object storage bucket.sandboxes.juicefs.name: a distinct name for the second release.sandboxes.juicefs.redis.metaURL: a distinct value, so each release uses its own JuiceFS metadata database rather than sharing metadata state with the first release.
Because the generated CSI node RBAC and secret-name helper are scoped to the installing release's namespace and values, you need to hand-write RBAC for the second release: a Role/RoleBinding for mounting and one for unmounting JuiceFS volumes, both bound to the ServiceAccount named juicefs-csi-node-sa.
The mounting Role, created in the installing (first) release's namespace, needs get/update/patch/delete on three secrets, named using the second release's own values following the same naming pattern the chart's helper uses:
juicefs-<juicefs.name>-secretjuicefs-<csi.pvName>-secretjuicefs-<csi.pvName>-host-secret
The second release's own namespace additionally needs a get permission on the CSI config secret (value csi.configSecretName, defaults to juicefs-csi-config). That secret can still point back to the installing release's ServiceAccount, since both releases share the same ServiceAccount and IRSA role for mount pods under external-driver mode.
Two releases can't currently share a single sandbox-host node. The sandbox-host's hard-coded host port binding means each Sandboxes-enabled release needs its own dedicated node(s) for its sandbox-host pods.
Note on chart versions
This CSI-driver RBAC-sharing setup applies to Helm chart versions that still ship the JuiceFS CSI driver integration (the csi.* values). A later major chart version (0.17) removes the CSI driver and RBAC integration entirely: sandbox-host mounts JuiceFS directly, and the cross-release RBAC setup described above is no longer needed. The host networking constraint (one sandbox-host pod per node due to a fixed host port) still applies in that later version, so you'll still need a dedicated node per Sandboxes-enabled release for that part.