---
title: Deployment Strategies (self-hosted)
description: Learn how to manage Langfuse effectively. It covers strategies for handling multiple projects and environments.
label: "Version: v4"
sidebarTitle: "Deployment Strategies"
---

# Deployment Strategies

Use this guide to learn how to manage Langfuse effectively. It covers strategies for handling multiple projects and environments.

When self-hosting Langfuse, there are several strategies you can use to manage projects and environments. This guide outlines the different approaches, their trade-offs, and implementation details to help you decide which strategy best suits your use case.

In most cases, a single Langfuse deployment is the best approach. It leverages RBAC (role-based access control) to separate data by organizations, projects, and user roles. However, certain use cases might require multiple deployments based on specific architectural or organizational needs.

## Single Langfuse Deployment

A single Langfuse deployment is the standard and recommended setup. It centralizes management, scales efficiently across projects and environments, and takes full advantage of Langfuse's built-in RBAC features.

```mermaid
graph TB
    subgraph AppVPC1["App/Env VPC 1"]
        App1[Application 1]
    end
    subgraph AppVPC2["App/Env VPC 2"]
        App2[Application 2]
    end
    subgraph AppVPCn["App/Env VPC N"]
        AppN[Application N]
    end
    subgraph CentralVPC["Langfuse VPC"]
        LF["Langfuse Service (logical separation of data)"]
    end

    App1 -- VPC Peering --> LF
    App2 -- VPC Peering --> LF
    AppN -- VPC Peering --> LF

    User["User/API/SDK"]
    LF -- Public Hostname and SSO --> User
```

### When to Use

- Your team can rely on Langfuse's RBAC to enforce data isolation.
- You want to minimize infrastructure complexity and operational overhead.

### Implementation Steps

1. Deploy Langfuse following the [self-hosting guide](/self-hosting).
2. Configure organizations and projects for each logical unit (e.g., team, client, or department).
3. Optional: Use [organization creators](/self-hosting/administration/organization-creators) and [project-level RBAC](/docs/rbac) roles to optimize permission management across teams and environments.

### Additional Considerations

- RBAC is critical to ensure proper data isolation. Plan your access control policies carefully.
- Langfuse is designed to be exposed publicly (see networking documentation). This approach simplifies access for stakeholders and eliminates complex network configurations, making it easier to integrate seamlessly across teams and projects.
- VPC peering can be used to access Langfuse privately across projects and environments, enhancing security and connectivity in centralized deployments.

## Langfuse Deployment for Each Service or Project

In this approach, you run a separate Langfuse deployment for each service, project, or environment. This provides complete isolation at the infrastructure level but comes with additional complexity.

Langfuse can be deployed via infrastructure as code (IaC) tools like Terraform or Helm, making this approach more manageable.

```mermaid
graph TB
    subgraph AppVPC1["App/Env VPC 1"]
        App1[Application 1]
        LF1["Langfuse Service"]
        App1 -- Within VPC --> LF1
    end
    subgraph AppVPC2["App/Env VPC 2"]
        App2[Application 2]
        LF2["Langfuse Service"]
        App2 -- Within VPC --> LF2
    end
    subgraph AppVPCn["App/Env VPC N"]
        AppN[Application N]
        LFn["Langfuse Service"]
        AppN -- Within VPC --> LFn
    end

    User["User/API/SDK"]
    LF1 -- VPN --> User
    LF2 -- VPN --> User
    LFn -- VPN --> User
```

### When to Use

- Compliance or regulatory requirements mandate strict data separation.

### Implementation Steps

1. Deploy Langfuse instances for each project or service by following the [self-hosting guide](/self-hosting). For example, you can use a Helm chart to seamlessly integrate Langfuse into your application stack.
2. Use [headless initialization](/self-hosting/administration/headless-initialization) to provision default organizations, projects, and API keys in each Langfuse instance when deploying it together with an application stack.
3. Provision access for users of each individual deployment and educate them about which Langfuse instances are available to them.

### Considerations

- **Higher Costs:** Each deployment requires dedicated resources, including infrastructure, maintenance, and updates.
- **Operational Complexity:** Managing multiple deployments can increase overhead for DevOps teams to scale and continuously [upgrade](/self-hosting/upgrade).
- **More difficult to adopt**: New teams cannot just get started but need to request deployment of an instance for the project or environment.
- **Cross-Project Visibility:** There is no shared view across projects or environments unless you build an external aggregation solution. Separating environments makes prompt deployment across instances more complex. It also makes it harder to sync datasets between production, staging, and development, limiting the ability to test edge cases and learn from production data.
- **Confusion of non-engineering teams:** Non-engineering teams might not understand the difference between Langfuse instances and how to use them.

## Choosing the Right Strategy

| Factor                  | Single Deployment                             | Multiple Deployments                                         |
| ----------------------- | --------------------------------------------- | ------------------------------------------------------------ |
| **Ease of Maintenance** | Centralized and simplified management         | Complex management with higher operational overhead          |
| **Ease of Adoption**    | Quick self-service via project creation in UI | Requires deployment requests and infrastructure provisioning |
| **Cost Efficiency**     | Optimized costs through shared infrastructure | Higher costs from duplicated infrastructure and maintenance  |
| **Data Isolation**      | Project-level isolation through RBAC controls | Complete physical and logical separation between deployments |
| **Scalability**         | Unified scaling of centralized infrastructure | Independent but duplicated scaling for each deployment       |
| **Compliance Needs**    | Suitable for standard compliance requirements | Required for strict regulatory isolation requirements        |
| **User Experience**     | Single interface with seamless project access | Multiple interfaces requiring additional user training       |

### General Recommendation

Start with a single Langfuse deployment and evaluate its scalability and data isolation capabilities. If specific needs arise that require isolated environments, consider moving to a multi-deployment approach for those cases. However, this is usually not recommended.

Please [reach out](/support) in case you have any questions on how to best architect your Langfuse deployment.

---

If you experience any issues when self-hosting Langfuse, please:

1. Check out [Troubleshooting & FAQ](/self-hosting/troubleshooting-and-faq) page.
2. Use [Ask AI](/ask-ai) to get instant answers to your questions.
3. Ask the maintainers on [GitHub Discussions](/gh-support).
4. Create a bug report or feature request on [GitHub](/issues).

  Enterprise-grade support is available when self-hosting Langfuse. Learn more on
  our [pricing page](/pricing-self-host).

<!-- agent-instructions -->

---

## Agent Instructions

This page is part of the [Langfuse](https://langfuse.com) documentation, published as plain Markdown for AI agents. Every page is available as Markdown by appending `.md` to its URL, or by sending an `Accept: text/markdown` header. This page: `https://langfuse.com/self-hosting/security/deployment-strategies.md`.

### Querying these docs

If the answer is not on this page, query the documentation instead of guessing:

- **Semantic search** across all Langfuse docs, returning an answer with the relevant pages and excerpts. Ask a specific, self-contained question:

  ```bash
  curl -sG "https://langfuse.com/api/search-docs" --data-urlencode "query=How do I trace a LangGraph agent?"
  ```

- **Index of every page**: <https://langfuse.com/llms.txt>, with per-section indexes [llms-docs.txt](https://langfuse.com/llms-docs.txt), [llms-integrations.txt](https://langfuse.com/llms-integrations.txt), and [llms-self-hosting.txt](https://langfuse.com/llms-self-hosting.txt).

### Before writing Langfuse code

- **Install the [Langfuse Agent Skill](https://langfuse.com/docs/api-and-data-platform/features/agent-skill).** It encodes Langfuse's own best practices for instrumentation, prompt management, and evaluation, and materially improves results.
- **Read [What does a good trace look like?](https://langfuse.com/docs/observability/best-practices.md)** before instrumenting an application.
- **Verify endpoints, parameters, and response fields** against the [API reference](https://api.reference.langfuse.com) instead of inferring them from code examples.
- **Use the [Langfuse CLI](https://langfuse.com/docs/api-and-data-platform/features/cli)** (`npx langfuse-cli api <resource> <action>`) to read or write traces, prompts, datasets, and scores from the terminal.

Found an error in these docs? Please open an issue at <https://github.com/langfuse/langfuse-docs/issues>.