Problem
Customers setting up LangGraph agent deployments on self-hosted LangSmith may encounter:
"Listeners" tab missing under Deployments in the UI
Error creating listeners: "Listeners cannot be created for LangSmith workspace ID '<id>'. Creating listeners is only allowed for LangSmith organizations with self-hosted enterprise plans."SSL certificate errors when the data plane listener connects to the control plane
Redis connection refused errors in the data plane
Applies To
Self-hosted LangSmith (air-gapped or internet-connected)
Hybrid LangSmith (self-hosted data plane + cloud control plane)
LangSmith versions
0.13.x+
Root Cause
The "Listeners" feature and deployment capability require specific feature flags to be enabled at the organization level in PostgreSQL. These flags are not enabled by default on self-hosted installations.
A stale Redis auth cache can also prevent newly-set flags from taking effect.
Solution
Step 1: Enable Required Feature Flags
Run against the LangSmith PostgreSQL instance:
kubectl exec langsmith-postgres-0 -n <namespace> -- psql -U postgres -d postgres -c \
"UPDATE organizations SET config = config || '{\"langgraph_enterprise_enabled\": true}';"
Also set the reconciler flag via Helm values:
commonEnv:
- name: DEFAULT_ORG_FEATURE_LANGGRAPH_REMOTE_RECONCILER_ENABLED
value: "true"
Step 2: Flush Redis Auth Cache
Stale cached auth responses may still reflect the old flag values:
kubectl exec langsmith-redis-0 -n <namespace> -- redis-cli --scan --pattern 'authInfo:*' \
| xargs -I {} kubectl exec langsmith-redis-0 -n <namespace> -- redis-cli DEL {}
kubectl exec langsmith-redis-0 -n <namespace> -- redis-cli --scan --pattern 'sharedAuth:*' \
| xargs -I {} kubectl exec langsmith-redis-0 -n <namespace> -- redis-cli DEL {}
Step 3: Restart Platform Backend
kubectl rollout restart deploy/langsmith-platform-backend -n <namespace>
Step 4: Verify Flags Are Set
Check org-level flags:
kubectl exec langsmith-postgres-0 -n <namespace> -- psql -U postgres -d postgres -c \
"SELECT id, config FROM organizations;"
Check workspace-level flags:
kubectl exec langsmith-postgres-0 -n <namespace> -- psql -U postgres -d postgres -c \
"SELECT id, config FROM tenants;"
Confirm langgraph_enterprise_enabled: true and langgraph_remote_reconciler_enabled: true appear in the config.
Step 5: Create Listener and Install Data Plane
After the flags are confirmed, the Deployments > Listeners tab should appear in the UI. Create a listener, then install the data plane Helm chart in your Kubernetes cluster.
Step 6: Verify Data Plane Connectivity
Check listener pods are running:
kubectl get pods -n <dataplane-namespace> | grep langgraph-dataplane
Check listener logs:
kubectl logs -l app.kubernetes.io/component=listener -n <dataplane-namespace> --tail=20
Healthy: Repeating
Enqueuing Job<function=reconcile_projects>messagesUnhealthy:
ConnectErrororConnectTimeout— verifyhostBackendUrlandsmithBackendUrlin your data plane Helm values
Common Follow-Up Issues
SSL Certificate Errors
If the listener logs show SSL: CERTIFICATE_VERIFY_FAILED, mount your CA certificate into the listener pod:
kubectl create configmap ca-cert --from-file=ca.crt=/path/to/your/ca-bundle.crt -n <dataplane-namespace>
Add to your dataplane-values.yaml:
listener:
deployment:
extraEnv:
- name: SSL_CERT_FILE
value: /etc/ssl/custom/ca.crt
- name: REQUESTS_CA_BUNDLE
value: /etc/ssl/custom/ca.crt
volumes:
- name: ca-cert
configMap:
name: ca-cert
volumeMounts:
- name: ca-cert
mountPath: /etc/ssl/custom
readOnly: true
Then upgrade the Helm release:
helm upgrade langgraph-dataplane langchain/langgraph-dataplane \
--namespace <dataplane-namespace> \
--values dataplane-values.yaml --wait
Redis Connection Refused in Data Plane
If listener logs show Error 111 connecting to ...redis:6379. Connection refused, verify the Redis service is running and accessible within the data plane namespace. Confirm the service name and port match what the Helm chart expects.
Deployment Stuck in "Queued" Status
This typically means the data plane listener hasn't successfully connected to the control plane yet. Resolve the connectivity issues above first, then the queued deployment should begin processing.