Skip to main content
Understand what the GCP Terraform modules provision and how the pieces fit together, so you can size, secure, and customize your LangSmith deployment before running make apply. Use this page as a reference while planning a rollout or troubleshooting an existing one. It covers:
  • Platform layers and deployment tiers (light versus production).
  • Module descriptions and dependencies.
  • Networking, Workload Identity, and traffic flow.
  • Add-ons: LangSmith Deployment, Fleet, Insights, and Polly.
  • GCP managed services and Secret Manager integration.
If you are ready to install, start with the deployment walkthrough.

Platform layers

LangSmith on GCP deploys in up to five stages. Each stage adds a capability layer on top of the previous. All layers share the same GKE cluster and langsmith namespace. LangSmith on GCP deployment stages and service layout
Fleet (chart v0.15+) is the current form of the feature formerly called Agent Builder. Enable it with enable_fleet. Unlike the deprecated enable_agent_builder path, it does not require the LangSmith Deployment layer. The two flags are mutually exclusive and share the same encryption key. See Enable add-ons in the deployment guide.

Module descriptions

Deployment tiers

Light deploy (all in-cluster)

Set in terraform.tfvars:

Production (external managed services)

Application core services

In-cluster ClickHouse is dev/POC only (single pod, no replication, no backups). For production, use LangChain Managed ClickHouse or a self-managed external cluster.
SmithDB is LangSmith’s purpose-built observability backend, available for Self-hosted starting with self-hosted version 0.16.0 (see deployment support). These Terraform modules provision ClickHouse, so the guidance in the previous sections applies to current deployments.

One-time jobs

LangSmith Deployment add-on

Each LangGraph deployment created in the UI produces a Kubernetes Deployment in the langsmith namespace, with pods running as the langsmith-ksa ServiceAccount. That ServiceAccount must carry the iam.gke.io/gcp-service-account annotation, which deploy.sh applies idempotently.

GCP managed services

When postgres_source = "external" and redis_source = "external" (the recommended production setting), Terraform provisions:

Cloud SQL PostgreSQL

  • Default size db-custom-2-8192 (2 vCPU, 8 GB), private IP, port 5432.
  • REGIONAL availability with automatic failover.
  • Holds orgs, users, projects, API keys, settings.
  • Terraform writes the connection URL directly to the langsmith-postgres-credentials Kubernetes Secret.

Memorystore Redis

  • Default 5 GB, STANDARD_HA tier, private IP, port 6379.
  • Trace ingestion queue, pub/sub, short-lived cache.
  • No auth token required. Access is controlled by VPC private IP only.
  • Terraform writes the connection URL directly to the langsmith-redis-credentials Kubernetes Secret.

Cloud Storage bucket

  • Trace payloads: large inputs and outputs, attachments.
  • The shipped Helm values use native GCS mode (engine: GCS, apiURL: https://storage.googleapis.com), authenticated through Workload Identity with no HMAC keys.
  • An S3-compatible mode (engine: S3) is also supported, shown in helm/values/examples/langsmith-values.yaml. It requires HMAC keys: create one under Cloud Storage → Settings → Interoperability and pass them to Helm via config.blobStorage.accessKey and config.blobStorage.accessKeySecret.
  • Lifecycle rules: ttl_s/ prefix (14 days default), ttl_l/ prefix (400 days default).
  • The GCS bucket is always required, regardless of tier.

Secret Manager (optional module)

  • Stores a single JSON secret bundle (generated LangSmith secret key, Postgres password, Redis password) when enable_secret_manager_module = true.
  • Core secrets (langsmith-postgres-credentials, langsmith-redis-credentials) are always stored in Kubernetes Secrets by k8s-bootstrap regardless of this module. Secret Manager provides an additional durable store for secrets that must survive cluster recreation.

Cluster infrastructure

The Gateway resource is managed by Terraform; the HTTPRoute is managed by Helm. Do not delete the Gateway resource manually. GCP releases the external IP when the Gateway is deleted, then issues a new IP on recreate.

Workload Identity

GKE pods access GCS through Workload Identity. The Kubernetes ServiceAccount is bound to a GCP service account via an IAM binding; pods receive temporary credentials with no static keys in Secrets or environment variables.
The GSA is defined by the iam module and output as workload_identity_annotation. init-values.sh writes these annotations into values-overrides.yaml automatically. In native GCS mode (the shipped default), the GSA bindings above are sufficient. The optional S3-compatible mode (engine: S3) also requires HMAC keys: create one under Cloud Storage → Settings → Interoperability and pass it to Helm.

Network topology

Cloud SQL and Memorystore are accessed exclusively via private IP. The networking module establishes a private service connection (VPC peering to Google’s managed network) whenever postgres_source = "external" or redis_source = "external".

Traffic flow

Component to storage mapping

Secret Manager integration

Without Secret Manager:
With Secret Manager:
Terraform writes the Kubernetes Secrets directly in both cases. Enabling Secret Manager adds a durable copy of the Postgres password, Redis password, and generated secret key outside the cluster. Nothing syncs Secret Manager back into the cluster, so no External Secrets Operator is installed on GCP (unlike the AWS modules, which use it to sync from SSM Parameter Store).

Terraform module graph

The infra layer does not install the LangSmith chart. The application stage installs it one of two ways, both consuming the same layered values files under helm/values/:
  • Deploy script: make init-values && make deploy runs helm upgrade --install.
  • Terraform app layer: make init-values && make init-app && make apply-app manages the chart as a helm_release resource. make init-app pulls the infra outputs (cluster, bucket, Workload Identity annotation) into app/infra.auto.tfvars.json, so the app layer reads them without a remote-state data source.

Verification commands