LangSmith Hosted vs Self: Deployment Guide 2026

TL;DR: LangSmith operates exclusively as a managed SaaS platform with no self-hosting option available as of 2026. Teams requiring on-premise LLM observability must evaluate open-source alternatives like Langfuse (MIT license, full self-hosting support), Phoenix by Arize AI (Apache 2.0, containerized deployment), or custom solutions built on OpenTelemetry. Choose SaaS LangSmith for zero-ops tracing with deep LangChain integration; choose self-hosted alternatives when data sovereignty, cost control, or compliance policies prohibit external trace storage.

Key Takeaways

• LangSmith is a SaaS-only platform with no official self-hosting option, making the "hosted vs self" decision actually a choice between LangSmith SaaS and open-source alternatives like Langfuse or Phoenix.
• Self-hosting LLM observability provides data sovereignty, cost predictability, and compliance control, but requires infrastructure expertise, operational overhead, and ongoing maintenance responsibility.
• Langfuse offers both managed SaaS and open-source self-hosting with Docker/Kubernetes deployment, making it the closest alternative to a "self-hosted LangSmith" architecture.
• Phoenix by Arize AI provides Apache 2.0 licensed observability optimized for notebook-based development and local debugging, with containerized deployment for production environments.
• Total cost comparison must include infrastructure, engineering time, data egress, and opportunity cost — self-hosting is not always cheaper despite eliminating SaaS subscription fees.
• The decision boundary is whether your organization's data governance, budget constraints, or customization requirements justify the operational complexity of running your own observability infrastructure.

What does LangSmith hosted versus self-hosted actually mean?

LangSmith, developed by LangChain Inc., is a managed observability platform delivered exclusively as Software-as-a-Service (SaaS). The platform has no self-hosting option, no enterprise on-premise deployment package, and no open-source release as of 2026. When organizations search for "LangSmith self-hosted," they are typically asking one of three questions:

1. Can I run LangSmith on my own infrastructure? No. LangSmith's codebase is proprietary.
2. What self-hosted alternatives provide similar capabilities? Langfuse and Phoenix are the primary options.
3. Should I accept SaaS for observability, or does my use case require self-hosting? This is the actual decision.

The comparison therefore becomes: LangSmith SaaS versus self-hosted open-source observability tools. Understanding this frame is critical before evaluating trade-offs, because "self-hosted LangSmith" does not exist.

Why would you want self-hosted LLM observability?

Organizations consider self-hosted observability for six primary reasons, each with concrete technical or business requirements.

Data Sovereignty and Compliance

When prompts contain personally identifiable information (PII), protected health information (PHI), or classified data, external SaaS storage may violate regulatory requirements. GDPR Article 48, HIPAA, FedRAMP, and defense classification policies often mandate on-premise data processing.

Concrete scenario: A healthcare AI assistant that discusses patient symptoms must comply with HIPAA. Sending trace data containing patient information to an external SaaS platform requires a Business Associate Agreement (BAA) and may still be prohibited by internal security policies. Self-hosting keeps patient data within the organization's security perimeter.

Cost Predictability at Scale

LangSmith pricing scales with trace volume: Developer plan ($39/month, 50K traces), Team plan ($199/month, 500K traces), Enterprise (custom pricing). An agent handling 10 million requests monthly with 10% trace sampling generates 1 million traces per month, pushing costs into four-figure monthly SaaS fees.

Self-hosted infrastructure cost is dominated by storage (traces persist for 180+ days) and compute (query performance). Organizations with existing Kubernetes clusters and object storage can deploy Langfuse at marginal cost: compute overhead for the API server, PostgreSQL database hosting, and S3-compatible storage. This becomes cost-effective above ~500K traces/month if engineering time is available.

Customization and Integration

Open-source observability tools allow custom evaluators, modified retention policies, and direct database access for internal analytics. SaaS platforms constrain customization to their API surface.

Example requirement: An organization wants to join trace data with internal experimentation metadata stored in Snowflake, then build custom dashboards in Tableau. Self-hosted PostgreSQL enables direct SQL access; SaaS platforms require API-based export with rate limits.

Air-Gapped and Restricted Networks

Defense contractors, financial institutions with segmented networks, and high-security research labs operate in environments where internet egress is blocked or tightly controlled. SaaS observability is impossible; self-hosted deployment on the internal network is the only option.

Avoiding Vendor Lock-In

Trace data, datasets, and evaluation results stored in a proprietary SaaS platform create migration friction. Self-hosted open-source tools provide portable data formats and direct database access, simplifying future migrations.

Control Over Feature Roadmap

SaaS platforms prioritize features benefiting their broad customer base. Self-hosted open-source tools can be forked, extended, or modified to meet niche requirements without waiting for vendor support.

How do LangSmith's SaaS-only constraints shape the comparison?

Because LangSmith does not offer self-hosting, the comparison cannot be apples-to-apples. Instead, evaluate:

The practical choice is therefore between accepting LangSmith's SaaS constraints for operational simplicity, or adopting a self-hosted alternative for control and compliance at the cost of operational complexity.

What are the leading self-hosted LangSmith alternatives?

Three open-source platforms dominate the self-hosted LLM observability space in 2026, each with different strengths and deployment patterns.

Langfuse: The Self-Hostable LangSmith Alternative

Langfuse is an MIT-licensed observability platform supporting both managed SaaS and self-hosting. It provides distributed tracing, prompt management, datasets, evaluations, and LLM-as-judge scoring. Langfuse is the most direct LangSmith alternative for teams requiring self-hosting.

Architecture:

• Next.js web application (TypeScript)
• PostgreSQL database for trace storage
• S3-compatible object storage for large payloads
• Optional Redis for caching
• Docker Compose or Kubernetes deployment

Self-hosting deployment:

Production deployments use Kubernetes with managed PostgreSQL (AWS RDS, GCP Cloud SQL) and object storage (S3, GCS, MinIO). Langfuse's Helm chart simplifies Kubernetes deployment with configurable replicas, autoscaling, and ingress.

LangChain integration:

When to choose Langfuse:

• Need self-hosting with feature parity closest to LangSmith
• Existing PostgreSQL and object storage infrastructure
• Kubernetes expertise available for production deployment
• MIT license acceptable for your organization
• Want option to use managed SaaS during prototyping, self-host in production

Phoenix: Notebook-First Observability for Local Development

Phoenix by Arize AI is an Apache 2.0 licensed observability tool optimized for notebook-based development and local debugging. It runs as a lightweight server within development environments, then scales to containerized deployment for production.

Architecture:

• Python application with FastAPI server
• SQLite (development) or PostgreSQL (production)
• Embedded web UI served from the Python process
• No external dependencies for basic usage

Local development deployment:

Production deployment:

Phoenix supports containerized deployment with PostgreSQL backend. Less feature-complete than Langfuse for prompt management and complex evaluations, but sufficient for tracing and basic debugging.

When to choose Phoenix:

• Primary use case is local development and debugging
• Want zero-setup local observability during prototyping
• Already using Arize AI for ML monitoring (unified platform)
• Apache 2.0 license required
• Prefer lightweight deployment over full-featured platform

OpenTelemetry + Jaeger: Custom Observability Stack

For maximum control, build custom LLM observability using OpenTelemetry for instrumentation and Jaeger for trace storage and visualization. This requires the most engineering effort but provides unlimited customization.

Architecture:

• OpenTelemetry SDK for trace instrumentation
• Jaeger for trace collection, storage (Cassandra/Elasticsearch), and UI
• Custom evaluators and dashboards built on raw trace data

This approach is appropriate only when neither Langfuse nor Phoenix meet specific technical requirements (e.g., integration with existing OpenTelemetry infrastructure, custom storage backends, regulatory constraints on using third-party platforms).

How do you actually self-host LLM observability in production?

Self-hosting requires planning beyond "run Docker Compose." Production deployment decisions affect reliability, cost, and operational burden.

Infrastructure Requirements

Compute:

• API server: 2-4 vCPU, 4-8 GB RAM for modest load (< 100 requests/sec)
• Worker processes: 1-2 vCPU per background job worker (evaluations, async processing)
• Auto-scaling: Horizontal pod autoscaling based on CPU/request rate

Storage:

• PostgreSQL: Primary datastore for traces, projects, users, datasets
• Estimated size: ~1 KB per trace, 1 million traces = ~1 GB uncompressed
• Retention: 180 days at 1M traces/month = ~180 GB
• Object storage: Large trace payloads, evaluation artifacts
• Estimated size: ~10-50 KB per large trace, varies by payload size

Networking:

• Ingress: HTTPS load balancer (AWS ALB, GCP Load Balancer, NGINX)
• TLS termination: Let's Encrypt or corporate certificate
• Egress: Outbound to LLM providers if evaluations use LLM-as-judge

Security Hardening

Authentication and Authorization:

• SSO integration (SAML, OAuth) for enterprise deployments
• API keys with role-based access control (RBAC)
• Audit logging for trace access and data export

Data Encryption:

• Encrypt at rest: Database encryption (AWS RDS encryption, GCP CMEK)
• Encrypt in transit: TLS 1.3 for all connections
• Secrets management: Vault, AWS Secrets Manager, or GCP Secret Manager

Network Isolation:

• Deploy in private subnet with no direct internet access
• Expose only via load balancer in public subnet
• Use VPC peering or PrivateLink for access from application VPCs

Operational Concerns

Backup and Recovery:

• Automated daily PostgreSQL backups with point-in-time recovery
• Object storage replication across availability zones
• Test restore procedures quarterly

Monitoring and Alerting:

• Infrastructure metrics: CPU, memory, disk, network via Prometheus/Datadog
• Application metrics: Request rate, error rate, latency
• Database metrics: Query performance, connection pool saturation
• Alert on: API downtime, database connection failures, disk space < 20%

Scaling:

• Horizontal scaling: Add API server replicas behind load balancer
• Database scaling: Read replicas for query-heavy workloads, vertical scaling for write-heavy
• Storage scaling: Object storage is effectively unlimited; PostgreSQL may require sharding above 10M traces

Upgrades and Maintenance:

• Follow Langfuse/Phoenix release notes for breaking changes
• Test upgrades in staging environment before production
• Schedule maintenance windows for database migrations
• Maintain version compatibility between SDK and server

What are the total cost models for hosted versus self-hosted?

Cost comparison requires modeling beyond subscription fees. Include infrastructure, engineering time, and opportunity cost.

LangSmith SaaS Cost Model

Direct costs:

• Developer plan: $39/month (50K traces)
• Team plan: $199/month (500K traces)
• Enterprise: Custom pricing, typically $1,000-2,000/month for 1-5M traces

Example: 1 million traces/month

• Team plan ($199/month) covers 500K traces
• Additional 500K traces requires Enterprise tier: ~$1,500/month
• Total: ~$1,500/month = $18,000/year

Hidden costs:

• None for infrastructure or operations
• Potential data egress fees if exporting large volumes
• Evaluation runs using LLM-as-judge incur additional LLM API costs

Langfuse Self-Hosted Cost Model

Infrastructure costs (AWS example, 1M traces/month):

• RDS PostgreSQL (db.t4g.large): $150/month
• S3 storage (180 GB retained): $4/month
• EKS cluster (2 nodes, t3.medium): $60/month
• ALB load balancer: $20/month
• Data transfer: $20/month
• Total infrastructure: ~$254/month = $3,048/year

Engineering costs:

• Initial deployment: 40-80 hours (1-2 weeks)
• Ongoing maintenance: 10-20 hours/month (monitoring, updates, incident response)
• Annual maintenance: 120-240 hours/year

Valuing engineering time:

• Junior DevOps: $75/hour
• Senior DevOps: $150/hour
• Initial deployment cost: $6,000-$12,000 (one-time)
• Annual maintenance cost: $9,000-$36,000

Total self-hosted cost (first year):

• Infrastructure: $3,048
• Initial deployment: $6,000-$12,000
• Maintenance: $9,000-$36,000
• Total: $18,048-$51,048

Total self-hosted cost (subsequent years):

• Infrastructure: $3,048
• Maintenance: $9,000-$36,000
• Total: $12,048-$39,048

Cost Comparison Summary

Cost crossover point: Self-hosting becomes cheaper if engineering time is below ~15 hours/month (junior engineer) or if trace volume grows significantly beyond 1M/month, where LangSmith Enterprise pricing increases but self-hosted infrastructure scales more linearly.

Non-financial costs:

• Self-hosting incurs opportunity cost: engineering time spent on observability infrastructure cannot be spent on product features
• SaaS incurs flexibility cost: cannot customize beyond API surface, cannot guarantee data residency in specific jurisdictions

How does data sovereignty affect the hosted versus self-hosted decision?

Data sovereignty requirements create hard constraints that override cost considerations. When regulatory or policy requirements mandate on-premise data processing, self-hosting is the only option.

Regulatory Compliance Scenarios

GDPR (Europe):

LangSmith offers EU data residency with data stored in European data centers. This satisfies most GDPR requirements if Data Processing Agreement (DPA) is executed. Self-hosting required only if internal policy prohibits third-party processors.

HIPAA (Healthcare, US):

LangSmith Enterprise includes Business Associate Agreement (BAA) for HIPAA compliance. Many healthcare organizations still prefer self-hosting to minimize PHI exposure, especially when prompts contain sensitive patient information.

FedRAMP (US Government):

LangSmith is not FedRAMP authorized as of 2026. Government contractors requiring FedRAMP compliance must self-host on FedRAMP-authorized infrastructure (AWS GovCloud, Azure Government) or use approved observability tools.

Defense Classification:

Classified systems operate on air-gapped networks with no external connectivity. SaaS observability is impossible; self-hosted deployment on SIPRNET or internal networks is mandatory.

Data Residency Technical Implementation

Self-hosting enables precise control over data location:

Multi-region deployment example:

• Deploy Langfuse instance in AWS `eu-west-1` for European users
• Deploy separate instance in AWS `us-east-1` for US users
• Route traces to region-specific instance based on user location
• No cross-region data transfer

On-premise deployment:

• Deploy Langfuse on Kubernetes cluster in corporate data center
• Use on-premise PostgreSQL and MinIO (S3-compatible storage)
• No data leaves corporate network
• Satisfies strictest data residency policies

What are the operational trade-offs between hosted and self-hosted?

Beyond cost and compliance, operational characteristics differ significantly between SaaS and self-hosted deployment.

Reliability and Availability

LangSmith SaaS:

• Uptime SLA: Typically 99.9% for paid plans (no public SLA published)
• Multi-region redundancy managed by LangChain Inc.
• Zero operational burden for disaster recovery
• Risk: Single vendor dependency, outage affects all customers simultaneously

Self-Hosted:

• Uptime depends on your infrastructure and operational practices
• Must implement own redundancy, backups, monitoring
• Full control over incident response and recovery
• Risk: Responsibility for 3 AM outages falls on your team

Upgrade Cadence and Features

LangSmith SaaS:

• Automatic feature updates with no action required
• New features available immediately upon release
• Breaking changes handled by vendor with migration guides
• Risk: Cannot delay updates if breaking change affects workflows

Self-Hosted:

• Control update schedule, test in staging before production
• Delayed access to new features until you upgrade
• Manual effort required for each upgrade
• Risk: Falling behind on updates creates technical debt, security vulnerabilities

Data Portability and Migration

LangSmith SaaS:

• Export via API with rate limits
• Proprietary storage format requires transformation for migration
• High friction to migrate to alternative platform
• Risk: Vendor lock-in increases over time as data accumulates

Self-Hosted:

• Direct database access, standard formats (PostgreSQL, S3)
• Can write custom export scripts without API constraints
• Easier migration to alternative tools or custom solutions
• Risk: Must maintain own data integrity and backup processes

When should you choose LangSmith SaaS versus self-hosted alternatives?

Decision framework based on organizational constraints and priorities:

Choose LangSmith SaaS When:

You are using LangChain heavily and want zero-friction tracing. LangSmith's native integration with LangChain provides automatic tracing with environment variable configuration. Self-hosted alternatives require explicit SDK integration.

Your trace volume is under 500K/month and engineering time is expensive. SaaS pricing is competitive at this scale, and operational burden is zero. Self-hosting requires DevOps expertise that could be spent on product development.

Data residency requirements are satisfied by LangSmith's US/EU regions. If regulatory compliance accepts third-party processing with DPA/BAA, SaaS removes operational complexity.

You prioritize rapid feature access and mature prompt management. LangSmith's Prompt Hub, evaluation features, and continuous updates provide the most complete feature set in the market.

Your organization lacks Kubernetes or infrastructure automation expertise. Operating self-hosted observability requires DevOps skills; SaaS eliminates this requirement.

Choose Self-Hosted Alternatives When:

Regulatory or policy requirements mandate on-premise data processing. Air-gapped networks, defense classification, or strict data residency policies prohibit external SaaS.

Trace volume exceeds 1 million/month and engineering resources are available. Cost crossover point favors self-hosting at scale if DevOps time can be allocated.

Customization beyond API limits is required. Direct database access enables custom analytics, integrations with internal data warehouses, and modified retention policies.

Vendor lock-in risk is unacceptable. Open-source self-hosting with PostgreSQL backend provides data portability and migration flexibility.

You need air-gapped deployment or network-restricted environments. Corporate networks blocking external API calls make SaaS observability impossible.

Hybrid Approach: Development SaaS, Production Self-Hosted

Many organizations use LangSmith SaaS during prototyping for rapid iteration, then migrate to self-hosted Langfuse for production to satisfy compliance requirements while benefiting from SaaS convenience during development. This requires maintaining SDK compatibility between platforms and accepting one-time migration effort.

What are common mistakes when deploying self-hosted LLM observability?

After observing dozens of self-hosted observability deployments, these failure patterns recur consistently.

Underestimating Operational Complexity

Symptom: Initial deployment succeeds, but system degrades over weeks due to lack of monitoring, backup testing, or upgrade planning.

Fix: Treat self-hosted observability as a production service requiring the same operational rigor as user-facing applications. Implement automated backups, monitoring dashboards, and documented runbooks before declaring deployment complete.

Inadequate Database Sizing

Symptom: Database runs out of disk space, queries become slow, or connection pool exhausts under load.

Fix: Model storage requirements based on trace volume and retention policy. Provision 3x expected capacity for growth headroom. Use managed database services (RDS, Cloud SQL) with automated scaling rather than self-managed PostgreSQL unless expertise exists.

Neglecting Security Hardening

Symptom: Default credentials, unencrypted databases, or publicly exposed API endpoints create security vulnerabilities.

Fix: Follow security checklist: change default passwords, enable database encryption at rest and in transit, deploy in private subnet with load balancer ingress only, integrate SSO authentication, enable audit logging.

No Disaster Recovery Testing

Symptom: Backups exist but have never been restored; when disaster strikes, recovery fails or takes days.

Fix: Schedule quarterly disaster recovery drills. Restore backup to staging environment, verify data integrity, measure recovery time objective (RTO). Document and automate recovery procedures.

Ignoring Upgrade Path

Symptom: Self-hosted platform falls multiple versions behind due to fear of breaking changes; accumulates technical debt and security vulnerabilities.

Fix: Subscribe to release notes, test upgrades in staging environment within one month of release, maintain version compatibility matrix between server and SDK versions.

Over-Engineering Initial Deployment

Symptom: Spending months architecting multi-region, highly available deployment before capturing first trace.

Fix: Start with single-region Docker Compose deployment on small VM, capture traces, prove value. Invest in Kubernetes, multi-region redundancy, and advanced monitoring only after demonstrating ROI from observability data.

FAQ

Can I self-host LangSmith?

No, LangSmith is a SaaS-only platform with no self-hosting option as of 2026. LangChain Inc. offers enterprise contracts with extended features, but the product architecture is proprietary and cannot be deployed on customer infrastructure. Organizations requiring self-hosted LLM observability must evaluate open-source alternatives like Langfuse (MIT license) or Phoenix by Arize AI (Apache 2.0 license), both of which provide LangSmith-like capabilities with full self-hosting support.

What is the closest self-hosted alternative to LangSmith?

Langfuse provides the closest feature parity to LangSmith with full self-hosting support. It includes distributed tracing, prompt management with versioning, datasets, evaluations, and LLM-as-judge scoring. Langfuse is MIT licensed and supports both Docker Compose and Kubernetes deployment. The platform integrates with LangChain through callback handlers (not as seamless as LangSmith's native integration, but functionally equivalent). Phoenix by Arize AI is a lighter-weight alternative optimized for local development, with optional containerized production deployment.

How much does it cost to self-host LLM observability?

Total cost includes infrastructure and engineering time. For 1 million traces per month with 180-day retention on AWS: infrastructure costs approximately $250/month (RDS PostgreSQL, S3 storage, EKS cluster, load balancer). Engineering costs dominate: 40-80 hours for initial deployment ($6,000-$12,000 one-time) and 10-20 hours per month for ongoing maintenance ($9,000-$36,000 annually, depending on engineer seniority). Total first-year cost ranges from $18,000 to $51,000. Subsequent years cost $12,000-$39,000. Self-hosting becomes cost-effective compared to LangSmith Enterprise pricing ($18,000/year for 1M traces) only if engineering time is below 15 hours/month or trace volume scales significantly higher.

Does LangSmith support on-premise deployment for enterprise customers?

No, LangSmith does not offer on-premise deployment even for enterprise customers. LangSmith Enterprise provides enhanced features (SSO, dedicated support, extended retention, compliance certifications), but the deployment model remains SaaS hosted by LangChain Inc. Data residency options include US and EU regions, and enterprise contracts include Data Processing Agreements (DPA) and Business Associate Agreements (BAA) for HIPAA, but the infrastructure is never deployed on customer premises. Organizations with hard on-premise requirements must use self-hosted alternatives.

What data does LangSmith store, and can it contain sensitive information?

LangSmith stores full traces including model inputs (prompts), outputs (completions), tool calls, tool results, metadata, and performance metrics. Prompts can contain highly sensitive information: user queries, PII, PHI, internal data, API keys accidentally logged, or business-critical context. If your LLM application processes regulated data (healthcare, financial, government), trace data inherits the same classification. LangSmith Enterprise provides encryption at rest, SOC 2 compliance, and BAA for HIPAA, but ultimately traces are stored on LangChain Inc. infrastructure. Self-hosting keeps this data within your security perimeter.

How do Langfuse and LangSmith compare for LangChain applications?

LangSmith provides deeper LangChain integration with zero-config tracing (set environment variables, tracing is automatic). Langfuse requires explicit callback handler instantiation and passing to each agent invocation. Functionally equivalent but slightly more code. LangSmith has more mature Prompt Hub with A/B testing; Langfuse's prompt management is simpler but functional. LangSmith evaluation features are more polished; Langfuse evaluations are sufficient for most needs. The key differentiator is deployment model: LangSmith is SaaS-only, Langfuse offers both SaaS and self-hosting. Choose LangSmith for convenience and feature maturity, Langfuse for self-hosting and open-source transparency.

Can I migrate from LangSmith to self-hosted Langfuse?

Yes, but migration requires effort. Export traces from LangSmith via API (subject to rate limits), transform to Langfuse's trace format, and import using Langfuse SDK. Datasets, prompts, and evaluation results also need transformation. No automated migration tool exists as of 2026. The process is feasible for teams with engineering resources but not trivial. Best practice: start with self-hosted Langfuse from day one if data sovereignty is a future requirement, avoiding migration costs. If already on LangSmith, justify migration effort based on compliance necessity or sustained cost savings, not just preference.

What compliance certifications does LangSmith provide?

LangSmith Enterprise includes SOC 2 Type II certification, GDPR compliance with Data Processing Agreement (DPA), and HIPAA compliance with Business Associate Agreement (BAA). The platform encrypts data at rest and in transit, supports SSO for authentication, and provides audit logging. However, LangSmith is not FedRAMP authorized, meaning US government contractors requiring FedRAMP compliance cannot use it. Defense and classified systems requiring air-gapped networks also cannot use SaaS LangSmith. Self-hosted alternatives deployed on FedRAMP-authorized infrastructure (AWS GovCloud, Azure Government) can satisfy stricter compliance requirements.

How does observability affect LLM application performance?

Tracing adds minimal latency overhead (typically < 5ms per traced operation) but introduces network calls to send traces asynchronously. LangSmith and self-hosted alternatives use background threads for trace submission, preventing blocking of application logic. Negligible impact on user-facing latency. Storage and bandwidth consumption scale with trace volume: 1 KB per simple trace, 10-50 KB for traces with large tool outputs. For high-volume applications (millions of requests/day), implement intelligent sampling: trace 100% of errors and user feedback, 1-10% of successful requests for statistical monitoring. This reduces costs by 90% without losing critical debugging data.

Sources

• LangSmith Official Documentation
• LangSmith Pricing and Plans
• Langfuse Open Source Observability Platform
• Langfuse Self-Hosting Documentation
• Phoenix by Arize AI on GitHub
• Phoenix Documentation and Deployment Guide
• OpenTelemetry for LLM Applications
• Jaeger Distributed Tracing