Enabling LangGraph Deployments on Self-Hosted LangSmith (Hybrid / Full Platform)

Last updated: April 7, 2026

Problem

Customers setting up LangGraph agent deployments on self-hosted LangSmith may encounter:

  1. "Listeners" tab missing under Deployments in the UI

  2. 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."

  3. SSL certificate errors when the data plane listener connects to the control plane

  4. 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> messages

  • Unhealthy: ConnectError or ConnectTimeout — verify hostBackendUrl and smithBackendUrl in 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.

Related Documentation