Skip to main content
Deploy LangSmith to GCP with the public Terraform modules. Managing the deployment as code lets you version, review, and reproduce your LangSmith environment across projects instead of clicking through the Google Cloud console. The install runs in two stages:
  1. Infrastructure: Terraform provisions VPC, GKE, Cloud SQL, Memorystore, GCS, and Workload Identity.
  2. Application: the LangSmith chart, installed with the deploy script or the Terraform app layer.
After the base install, enable optional add-ons by setting flags and redeploying.

Prerequisites

Required tools

Install on macOS:

Required GCP APIs

Terraform enables these automatically on first apply, but cloudresourcemanager.googleapis.com must be enabled first so Terraform can enable the rest. Enable everything manually for fast first runs:

Required IAM roles

The principal running Terraform needs the following roles on the target project. Trim to least-privilege after the initial deployment is stable.

Authenticate

You also need a LangSmith license key (contact sales) and a domain or subdomain that resolves to GCP.

Quickstart

For a condensed cheat sheet of make targets, required variables, and common constraints, see the GCP quick reference.
For the fastest path from zero to a running LangSmith instance, run these commands in order:
The following sections cover each phase in detail.

Provision infrastructure

Terraform provisions the following GCP resources:

Clone and configure

All subsequent commands run from modules/gcp/. Run make help for the full target list. Generate terraform.tfvars with the interactive wizard:
The wizard prompts for project ID, naming prefix, region, GKE sizing, TLS source, external vs in-cluster services, and the optional add-on flags. It writes infra/terraform.tfvars. Re-running preselects existing values; press Enter at each prompt to keep the current config. Prefer to edit manually:
The minimum required variables:
See the GCP variables reference for every input variable.
Configure a remote state backend before applying. Copy infra/backend.tf.example to infra/backend.tf and point it at a GCS bucket you control. Local state is fragile and can be lost during directory restructuring.

Load secrets into Secret Manager

The script reads terraform.tfvars, derives the secret prefix, and for each secret either reuses an exported value, reads the existing Secret Manager secret, auto-generates one (for salts and Fernet keys), or prompts you. The license key and admin password are the two values you supply interactively. The script must be sourced because make cannot export environment variables back to the parent shell. Verify the secrets are present:

Preflight checks

make preflight validates that the active gcloud credentials can perform each required action, that the required GCP APIs are enabled, and that the target region has the SKUs the modules request. Catching gaps here is faster than discovering them mid-terraform apply.

Apply

Provisioning the GCP cloud foundation takes 25 to 35 minutes on a clean project. Do not interrupt the apply.
make plan shows the proposed diff. Review the output before applying. make apply provisions in dependency order: VPC and networking, then GKE (about 10 to 15 minutes), private service connection, Cloud SQL (about 10 minutes with HA), Memorystore, GCS, and the bootstrap workloads. Equivalent direct Terraform flow:

Configure kubectl

All nodes should report Ready.

Verify bootstrap components

cert-manager, KEDA, and the LangSmith namespace secrets should all be in place.

Deploy LangSmith

Use one of the three supported deployment paths: Two commands install the LangSmith chart with sensible defaults wired from Terraform outputs:
init-values.sh prompts for the admin email, then reads sizing_profile and the enable_* flags from terraform.tfvars and copies matching values files from helm/values/examples/ into helm/values/. It also generates values-overrides.yaml with your hostname, Workload Identity annotations, and GCS bucket name. make deploy runs helm/scripts/deploy.sh, which refreshes the kubeconfig, runs preflight checks, applies the layered values files, and runs helm upgrade --install. Expect 8 to 12 minutes for the chart to install and pods to become ready. If you completed the script-driven deploy, skip to Verify and configure DNS. The following two paths are alternatives to the script-driven deploy.

Terraform-managed Helm release

Keep the entire deployment under Terraform. The app layer wraps the same chart and layered values files as the deploy script, managed as a helm_release resource.
Set app-layer inputs in app/terraform.tfvars (admin_email is required; hostname, chart_version, sizing, and the enable_* flags are optional). The app layer uses its own variable names: sizing (not sizing_profile) and enable_agent_deploys (not enable_deployments). make init-app populates the infra-derived inputs (cluster, bucket, Workload Identity annotation) into app/infra.auto.tfvars.json. The release is applied with wait = false because operator-spawned agents can take 10+ minutes on a cold cluster; a passing terraform apply means the release was accepted, not that every pod is ready. If you completed the Terraform-managed Helm release, skip to Verify and configure DNS. The following path is an alternative.

Manual Helm install

Best for teams running helm directly without the scripts. Generate the required secrets first:
The shipped helm/values/values.yaml sets config.blobStorage.engine: GCS (native GCS mode), so blob storage authenticates through Workload Identity with no HMAC keys. The per-component Workload Identity annotations live in values-overrides.yaml; generate it with make init-values, or add each component’s serviceAccount.annotations."iam.gke.io/gcp-service-account" by hand.
To use S3-compatible blob storage instead of Workload Identity, add --set config.blobStorage.engine=S3 and pass HMAC keys with --set config.blobStorage.accessKey=<key> and --set config.blobStorage.accessKeySecret=<secret>. Create the HMAC key under Cloud Storage → Settings → Interoperability.

Verify and configure DNS

cert-manager cannot issue the Let’s Encrypt certificate until the DNS A record resolves to the Gateway IP. Create the record at your DNS provider, wait for propagation, then re-check the certificate status.

Sizing profiles

Set sizing_profile in terraform.tfvars, then re-run make init-values && make deploy.

Expected pods

Enable add-ons

Each add-on is gated by a flag in infra/terraform.tfvars. Set the flag, re-apply Terraform, then re-run make init-values && make deploy.

LangSmith Deployment

Adds host-backend, listener, and operator. Required before enabling Agent Builder or Insights. KEDA is installed automatically when enable_langsmith_deployment = true.
Verify:
config.deployment.url must include https://. Without the protocol, operator-spawned agents stay stuck in DEPLOYING indefinitely.

Fleet

Fleet is the current form of the feature formerly called Agent Builder, deployed as a standalone service (chart v0.15+).
You can enable Fleet with enable_fleet. Unlike the deprecated enable_agent_builder path, it does not require LangSmith Deployment. Terraform provisions a dedicated fleet database on Cloud SQL and wires the langsmith-fleet-postgres and langsmith-fleet-redis secrets to the existing Cloud SQL and Memorystore instances. Fleet reuses langsmith_agent_builder_encryption_key, so migrating from enable_agent_builder keeps the same key and data.
Fleet requires the LangSmith Helm chart >=0.15.0 and the Agent Builder or Fleet entitlement in your license.
Verify:
Do not enable enable_fleet and enable_agent_builder together. The Fleet values file sets config.agentBuilder.enabled: false, so the two add-ons are mutually exclusive.

Agent Builder (deprecated)

On GCP, enable_agent_builder is deprecated in favor of Fleet (enable_fleet, chart v0.15+). Use Fleet for new deployments. This section documents the older path for existing installs.
Prerequisite: LangSmith Deployment healthy. Adds agent-builder-tool-server, agent-builder-trigger-server, and an agentBootstrap Job that registers the Polly agent URL.
Verify:
Roll the frontend after agentBootstrap completes so it picks up the langsmith-polly-config ConfigMap:
Skipping the frontend restart makes Polly show “Unable to connect to LangGraph server”.

Insights and Polly

Prerequisite: Agent Builder healthy. Insights enables ClickHouse-backed trace analytics. Polly is the AI eval and monitoring agent. Enable both together.
Verify:
insights_encryption_key and polly_encryption_key must never change after first enable. Rotating either permanently breaks existing encrypted data.

Expected pods by add-on

LangSmith Deployment adds: langsmith-host-backend, langsmith-listener, langsmith-operator. Fleet adds: standalone-fleet-api-server, standalone-fleet-tool-server, standalone-fleet-trigger-server, standalone-fleet-queue. Agent Builder adds: langsmith-agent-builder-tool-server, langsmith-agent-builder-trigger-server, langsmith-agent-builder-bootstrap (Completed), agent-builder-<hash> (operator-spawned). Insights and Polly add: clio-<hash> (Insights analytics), smith-polly-<hash> (Polly agent), lg-<hash>-0 (LangGraph StatefulSet).

Key watchouts

  • config.deployment.url must include https://. Without it, operator-spawned agents stay stuck in DEPLOYING.
  • config.deployment.enabled: true is required for LangSmith Deployment. Setting only the URL without enabled: true causes the chart to silently skip listener and operator.
  • Encryption keys must never change after first enable. Rotating insights_encryption_key or polly_encryption_key permanently breaks existing encrypted data.
  • Roll the frontend after first Polly enable. agentBootstrap creates the langsmith-polly-config ConfigMap after registering. Frontend pods started before bootstrap completes do not pick it up automatically.
  • Envoy Gateway IP changes on teardown. GCP releases the external IP when the Gateway is deleted. After a re-apply, a new IP is issued, so update your DNS A record.
  • langsmith-ksa annotation is not permanent. The operator creates langsmith-ksa at runtime; it does not survive namespace deletion. deploy.sh re-annotates it idempotently. Re-run make deploy if operator pods lose GCS access after a cluster rebuild.

Next steps