BYOC architecture on Azure

BYOC on Azure runs the LangSmith data plane in a resource group in your Azure subscription, while LangChain runs the control plane in its own Azure environment in centralus. Your trace data stays in your subscription. This page describes what LangSmith deploys, how traffic flows, the access LangSmith gets, and how your data is protected. For BYOC on AWS, see BYOC architecture. To set up a data plane, follow BYOC onboarding on Azure.

​

Control plane and data plane

The lifecycle of a data plane is:

1. You apply the LangSmith Terraform module, which creates a resource group and a Key Vault, and gives the LangSmith BYOC application two roles on the resource group.
2. You create the data plane with the LangSmith API. The control plane checks its access, and writes the data plane’s bootstrap secret to your Key Vault.
3. The control plane creates the network, AKS cluster, databases, and storage in the resource group, then installs LangSmith on the cluster.
4. The data plane reports to the control plane, and its status becomes active.
5. LangChain upgrades, scales, and repairs the data plane until you delete it.

​

What gets deployed

LangSmith creates all data plane resources in your resource group. AKS also creates a node resource group, <name>-smith-aks-nodes, and manages it.

​

Network

LangSmith creates a VNet from the vpc_cidr range in the create request, and divides it into subnets. For a /16 VNet: One network security group on the private endpoint subnet uses three application security groups to allow traffic from the AKS subnet only: TCP 5432 to PostgreSQL endpoints, TCP 10000 and 8500 to 8599 to Redis endpoints, and TCP 443 to Blob storage, Key Vault, and control plane endpoints. The AKS subnet takes one sixteenth of the VNet, and the private endpoint subnet takes 1/256 of it. A /18 VNet gives a /22 AKS subnet and a /26 private endpoint subnet. The Kubernetes service range comes from outside the VNet: 10.240.0.0/16, or 192.168.0.0/16 if your VNet overlaps 10.240.0.0/16. Private DNS zones linked to the VNet resolve PostgreSQL, Redis, Key Vault, and Blob storage to their private endpoints.

​

Compute

• AKS: Kubernetes 1.35 on the Standard tier. A private cluster with no public API endpoint. Local accounts and run command are disabled. Authentication uses Microsoft Entra ID with Azure RBAC for Kubernetes authorization. The OIDC issuer and workload identity are enabled.
• Network plugin: Azure CNI with Cilium for the data path and network policy.
• System node pool: Three Standard_D2s_v6 nodes on Azure Linux, spread across the region’s availability zones, reserved for critical add-ons.
• Application nodes: Node auto-provisioning adds and removes nodes as pods need them. It uses on-demand D, E, and F series VMs of version 5 or later. Each node pool has a CPU and memory limit. The general pool is limited to 100 vCPUs and 400 GiB of memory. SmithDB runs on its own pools, including a pool of VMs with local NVMe disks for its cache.
• Upgrades: AKS applies Kubernetes patch versions and node image updates automatically, in the data plane’s maintenance window.

​

Data stores

Data planes store and query traces in SmithDB, with its data in Blob storage and its metadata in the SmithDB PostgreSQL server. They do not run ClickHouse.

​

DNS and ingress

• Hostname: <data_plane_id>.azure.langchain-byoc.com. LangSmith creates a public DNS zone for the hostname in your resource group and delegates it from the parent zone that LangChain owns.
• Load balancer: An Azure Standard load balancer, public or internal, as set by public_load_balancer in the create request.
• Private DNS: For an internal load balancer, the hostname resolves through a private DNS zone linked to the data plane VNet. The public zone holds certificate validation records, not the internal endpoint address. Your users and applications need DNS resolution through the private zone.
• Ingress: An Istio ingress gateway. HTTP redirects to HTTPS, and the gateway rejects the TRACE, TRACK, and CONNECT methods.
• TLS: cert-manager gets a Let’s Encrypt certificate for the hostname through a DNS-01 challenge.

​

Identities

Data plane workloads use user-assigned managed identities in your resource group, through workload identity federation with the AKS OIDC issuer. No storage keys, database passwords, or client secrets exist. Each identity has only the roles its workload needs, such as a data role on one Blob container, the PostgreSQL database role, or Key Vault Secrets User on the vault.

​

Connectivity

The data plane pulls LangSmith container images from LangChain’s container registry through the NAT gateway. The data plane sends operational data to the control plane, such as authentication requests, health metrics, and usage. As on AWS, the LangSmith UI loads static assets from the control plane and sends every request for application data to your data plane. See Data traffic.

​

Access and permissions

LangChain manages your data plane through one multi-tenant Microsoft Entra application, LangSmith BYOC. You add its service principal to your tenant and give it roles on each data plane resource group. The application requests no Microsoft Graph permissions. The control plane holds no stored credential for your tenant. It runs on AKS, and workload identity federation exchanges a pod token for a token of the LangSmith BYOC application in your tenant. Only the control plane services that provision and manage data planes can get that token.

​

Role assignments

The Terraform module creates one custom role per data plane, with the resource group as its only assignable scope. Both role assignments carry your organization’s external ID as their description. LangSmith refuses to create a data plane when they do not match, which binds the resource group to your LangSmith organization.

​

What LangChain can and cannot access

To remove LangSmith’s access, see Remove LangSmith access.

​

Data protection

​

Encryption

​

Retention

• Trace payloads: Blob lifecycle rules delete each object when its retention tier ends. The defaults are 14 days for short-lived traces and 400 days for long-lived traces. You can change both with the ttl setting. See Change data plane settings.
• Blob versions: Versioning is enabled, and previous versions are deleted 7 days after they are created. Deleted containers can be restored for 7 days. Blob soft delete is disabled, so expired traces do not outlive their retention tier.
• PostgreSQL: Automated backups are kept for 7 days in the same region.
• Redis: No persistence and no backups. Redis holds only short-lived data.

​

Deletion

When you delete a data plane, LangSmith deletes the AKS cluster, PostgreSQL, Redis, and the network resources. It keeps your resource group, your Key Vault, and the Blob storage accounts that hold trace and SmithDB data. For details, see Delete a data plane.

​

Scaling and operations

LangChain operates Azure data planes the same way as AWS data planes. See BYOC operations for upgrades and maintenance. On Azure:

• Application services: Each LangSmith service scales horizontally between its minimum and maximum replica counts. Most services target 70% CPU and 80% memory of their requested resources.
• Nodes: Node auto-provisioning adds nodes for pods that cannot be scheduled, up to each node pool’s limit. The system node pool stays at three nodes.
• Storage: PostgreSQL storage grows automatically. Blob storage grows with usage.
• Monitoring: The data plane reads PostgreSQL and Redis metrics from Azure Monitor, and reports health metrics to LangChain.
• Changes: LangChain monitors the data plane and can change database sizes, replica counts, and node pool limits.

​

Logs

Your Azure Activity Log records every call that LangSmith makes to Azure Resource Manager. LangSmith does not configure Azure diagnostic settings or VNet flow logs, so AKS control plane and audit logs, Key Vault audit logs, PostgreSQL logs, and network flow logs are not collected by default. To collect them, add diagnostic settings and flow logs to those resources in your subscription. You are responsible for reviewing the logs and configuring alerts.

​

See also

• BYOC overview
• BYOC onboarding on Azure
• BYOC shared responsibility model

---