LangSmith BYOC moves the data plane into your VPC on AWS, Azure, and Google Cloud
On November 3, 2026, LangChain announced LangSmith BYOC is generally available on AWS and in beta on Azure and Google Cloud: traces, evals, and agent deployments stay in your own cloud account while LangChain operates the infrastructure. Teams under compliance constraints can drop self-hosting without repatriating maintenance or migrating their data.
November 3, 2026. LangChain announces that LangSmith BYOC — Bring Your Own Cloud — is generally available on AWS and enters beta on Azure and Google Cloud. November 3, 2026, same day. The pitch fits one line: your traces, evals, datasets, prompts, and agent deployments stay in your own cloud account, on the cloud you choose, while LangChain operates the data plane — orchestration, scaling, updates. November 3, 2026, again. The news is the extension of a service launched on AWS in August to the other two major clouds, each built on native infrastructure. The bottom line: agent observability stops being a trade-off between “your data at the vendor” and “maintain everything yourself.”
For a platform team shipping agents to production, this closes a painful gap between compliance and operational burden.
The control-plane / data-plane split
BYOC splits LangSmith in two. LangChain runs the control plane, which holds authentication, org and workspace configuration, billing metadata, hashed API keys, and static UI assets. You own the data plane, which holds everything sensitive: traces, prompts, datasets, experiments, agent deployments, and workspace secrets.
The split has a practical consequence: an organization can hold several data planes, each in its own account and region, each carrying its own workspaces. A platform team can run production and staging data planes in separate AWS accounts while a business unit standardized on Azure operates its own BYOC deployment. Each team’s traces land in the account that team owns — and answers for before its CISO.
This is exactly what self-hosting could not deliver without pain. Until now, teams with strict compliance boundaries deployed LangSmith self-hosted: the data stayed inside their perimeter, but dedicated platform engineers had to patch stateful services, configure databases, and run schema migrations.
What it looks like on each cloud
The service is built from each provider’s native building blocks — and that is what separates it from a lowest-common-denominator “cloud-agnostic” product.
On AWS, the data plane runs inside your existing VPC, with the database in the subnets you choose. Security teams can attach their own security groups to each application role, so the data plane slots into the ingress and egress inspection policies you already enforce.
On Azure, the data plane runs in a dedicated virtual network with a private AKS endpoint. LangChain deploys Istio and KEDA via Helm for ingress routing and event-driven scaling, and system telemetry flows to Azure Monitor. Support for LangSmith Sandboxes on Azure is coming soon.
On Google Cloud, data planes can run in any region at launch, managed from LangSmith’s US control plane. Resources use namespace-scoped names so they do not collide with your existing infrastructure.
Across all three clouds, BYOC data planes also expose Managed Deep Agents endpoints. And the data plane’s LLM Gateway calls models from 11 providers out of the box, plus any OpenAI- or Anthropic-compatible endpoint — so you choose the model provider as well as the cloud.
Migrating off self-hosting without starting over
The thing that usually decides between staying self-hosted and switching is data migration. LangChain has made it non-destructive.
Migration happens in two steps. Workspace resources move with an open-source migration tool (langchain-ai/langsmith-data-migration-tool) that reads your self-hosted instance and leaves it intact and live during the move. On every cloud it covers users and roles, datasets, experiments, and prompts, plus annotation queue configuration, automation rules, dashboards, and Fleet resources. Traces, runs, and feedback move in a second step operated by LangChain with internal tooling — trace migration is available on AWS only today.
On transparency, the Terraform modules behind BYOC are public (github.com/langchain-ai/terraform), as is the migration tool. That is a meaningful difference from an opaque managed service: you can audit the shape of the infrastructure before deploying it into your account.
What to verify before signing
The model is not magic, and three points deserve a close look.
- The shared responsibility model. You remain accountable for account compliance, encryption keys, and network access; LangChain operates scaling and updates. Read the documented matrix before pointing the data plane at sensitive workloads.
- The scoped IAM role. Setup runs through a Terraform module that creates a delimited IAM role: confirm the granted permissions match the strict minimum, not an over-broad role.
- Google Cloud regional limits. At launch the control plane is US-based: if your data-residency policy requires a local control plane, the GCP beta is not your path yet.
The rest — continuous upgrades, LangSmith features delivered shortly after they ship on cloud, automatic scaling — is the benefit AWS customers have reported since August, now generalized across clouds.
Verdict
BYOC is worth the move for a specific population: teams already running LangSmith self-hosted for compliance reasons, or those refusing LangSmith Cloud because traces leave their perimeter. If that is you, the open-source migration and the operated data plane remove most of the cost you were carrying — the decision is clean on AWS (GA), more cautious on Azure and GCP (beta). If your data can already live at the vendor, stay on LangSmith Cloud: the overhead of a BYOC data plane only pays for itself behind a compliance boundary, not for comfort.