DocsSelf-hostSelf-host (docker)

Self-Hosting Langfuse - Open Source LLM Observability

Docker Image

Langfuse Server, which includes the API and Web UI, is open-source and can be self-hosted using Docker.

For a detailed component and architecture diagram, refer to CONTRIBUTING.md.

Looking for a managed solution? Consider Langfuse Cloud maintained by the Langfuse team.

Prerequisites: Postgres Database

Langfuse requires a persistent Postgres database to store its state. You can use a managed service on AWS, Azure, or GCP, or host it yourself. Once the database is ready, keep the connection string handy. At least version 12 is required.

Deploying the Application

Deploy the application container to your infrastructure. You can use managed services like AWS ECS, Azure Container Instances, or GCP Cloud Run, or host it yourself.

During the container startup, all database migrations will be applied automatically. This can be optionally disabled via environment variables.

docker pull langfuse/langfuse:2
docker run --name langfuse \
-e DATABASE_URL=postgresql://hello \
-e NEXTAUTH_URL=http://localhost:3000 \
-e NEXTAUTH_SECRET=mysecret \
-e SALT=mysalt \
-e ENCRYPTION_KEY=0000000000000000000000000000000000000000000000000000000000000000 \ # generate via: openssl rand -hex 32
-p 3000:3000 \
-a STDOUT \
langfuse/langfuse

We follow semantic versioning for Langfuse releases, i.e. breaking changes are only introduced in a new major version.

  • We recommend automated updates within a major version to benefit from the latest features, bug fixes, and security patches (docker pull langfuse/langfuse:2).
  • Subscribe to our mailing list to get notified about new releases and new major versions.

For production environments, we suggest using a configuration of 2 CPU cores and 3 GB of RAM for the Langfuse container. On AWS, this would equate to a t3.medium instance. The container is stateless, allowing you to autoscale it based on actual resource usage.

Configuring Environment Variables

Langfuse can be configured using environment variables (.env.prod.example). Some are mandatory as defined in the table below:

VariableRequired / DefaultDescription
DATABASE_URLRequiredConnection string of your Postgres database. Instead of DATABASE_URL, you can also use DATABASE_HOST, DATABASE_USERNAME, DATABASE_PASSWORD and DATABASE_NAME.
DIRECT_URLDATABASE_URLConnection string of your Postgres database used for database migrations. Use this if you want to use a different user for migrations or use connection pooling on DATABASE_URL. For large deployments, configure the database user with long timeouts as migrations might need a while to complete.
SHADOW_DATABASE_URLIf your database user lacks the CREATE DATABASE permission, you must create a shadow database and configure the “SHADOW_DATABASE_URL”. This is often the case if you use a Cloud database. Refer to the Prisma docs for detailed instructions.
NEXTAUTH_URLRequiredURL of your deployment, e.g. https://yourdomain.com or http://localhost:3000. Required for successful authentication via OAUTH.
NEXTAUTH_SECRETRequiredUsed to validate login session cookies, generate secret with at least 256 entropy using openssl rand -base64 32.
SALTRequiredUsed to salt hashed API keys, generate secret with at least 256 entropy using openssl rand -base64 32.
ENCRYPTION_KEYRequiredUsed to encrypt sensitive data. Must be 256 bits, 64 string characters in hex format, generate via: openssl rand -hex 32.
LANGFUSE_CSP_ENFORCE_HTTPSfalseSet to true to set CSP headers to only allow HTTPS connections.
PORT3000Port the server listens on.
HOSTNAMElocalhostIn some environments it needs to be set to 0.0.0.0 to be accessible from outside the container (e.g. Google Cloud Run).
LANGFUSE_DEFAULT_ORG_IDConfigure optional default organization for new users. When users create an account they will be automatically added to this organization.
LANGFUSE_DEFAULT_ORG_ROLEVIEWERRole of the user in the default organization (if set). Possible values are OWNER, ADMIN, MEMBER, VIEWER. See roles for details.
LANGFUSE_DEFAULT_PROJECT_IDConfigure optional default project for new users. When users create an account they will be automatically added to this project.
LANGFUSE_DEFAULT_PROJECT_ROLEVIEWERRole of the user in the default project (if set). Possible values are OWNER, ADMIN, MEMBER, VIEWER. See roles for details.
SMTP_CONNECTION_URLConfigure optional SMTP server connection for transactional email. Connection URL is passed to Nodemailer (docs).
EMAIL_FROM_ADDRESSConfigure from address for transactional email. Required if SMTP_CONNECTION_URL is set.
S3_ENDPOINT
S3_ACCESS_KEY_ID
S3_SECRET_ACCESS_KEY
S3_BUCKET_NAME
S3_REGION
Optional S3 configuration for enabling large exports from the UI. S3_BUCKET_NAME is required to enable exports. The other variables are optional and will use the default provider credential chain if not specified.
DB_EXPORT_PAGE_SIZE1000Optional page size for streaming exports to S3 to avoid memory issues. The page size can be adjusted if needed to optimize performance.
LANGFUSE_AUTO_POSTGRES_MIGRATION_DISABLEDfalseSet to true to disable automatic database migrations on docker startup.
LANGFUSE_LOG_LEVELinfoSet the log level for the application. Possible values are trace, debug, info, warn, error, fatal.
LANGFUSE_LOG_FORMATtextSet the log format for the application. Possible values are text, json.
NEXT_PUBLIC_BASE_PATHSet the base path for the application. This is useful if you want to deploy Langfuse on a subpath, especially when integrating Langfuse into existing infrastructure. Refer to the section below for details.

Authentication

Email/Password

Email/password authentication is enabled by default. Users can sign up and log in using their email and password.

To disable email/password authentication, set AUTH_DISABLE_USERNAME_PASSWORD=true. In this case, you need to set up SSO instead.

If you want to provision a default user for your Langfuse instance, you can use the LANGFUSE_INIT_* environment variables.

Password Reset

  • If transactional emails are configured on your instance via the SMTP_CONNECTION_URL and EMAIL_FROM_ADDRESS environments, users can reset their password by using the “Forgot password” link on the login page.

  • If transactional emails are not set up, passwords can be reset by following these steps:

    1. Update the email associated with your user account in database, such as by adding a prefix.
    2. You can then sign up again with a new password.
    3. Reassign any organizations you were associated with via the organization_memberships table in database.
    4. Finally, remove the old user account from the users table in database.

SSO

To enable OAuth/SSO provider sign-in for Langfuse, add the following environment variables:

ProviderVariablesOAuth Redirect URL
GoogleAUTH_GOOGLE_CLIENT_ID
AUTH_GOOGLE_CLIENT_SECRET

AUTH_GOOGLE_ALLOW_ACCOUNT_LINKING=true (optional)
AUTH_GOOGLE_ALLOWED_DOMAINS=langfuse.com,google.com(optional, list of allowed domains based on hd OAuth claim)
/api/auth/callback/google
GitHubAUTH_GITHUB_CLIENT_ID
AUTH_GITHUB_CLIENT_SECRET

AUTH_GITHUB_ALLOW_ACCOUNT_LINKING=true (optional)
/api/auth/callback/github
GitLabAUTH_GITLAB_CLIENT_ID
AUTH_GITLAB_CLIENT_SECRET

AUTH_GITLAB_ISSUER (optional)
AUTH_GITLAB_ALLOW_ACCOUNT_LINKING=true (optional)
/api/auth/callback/gitlab
AzureAD/Entra IDAUTH_AZURE_AD_CLIENT_ID
AUTH_AZURE_AD_CLIENT_SECRET
AUTH_AZURE_AD_TENANT_ID

AUTH_AZURE_ALLOW_ACCOUNT_LINKING=true (optional)
/api/auth/callback/azure-ad
OktaAUTH_OKTA_CLIENT_ID
AUTH_OKTA_CLIENT_SECRET
AUTH_OKTA_ISSUER

AUTH_OKTA_ALLOW_ACCOUNT_LINKING=true (optional)
/api/auth/callback/okta
Auth0AUTH_AUTH0_CLIENT_ID
AUTH_AUTH0_CLIENT_SECRET
AUTH_AUTH0_ISSUER

AUTH_AUTH0_ALLOW_ACCOUNT_LINKING=true (optional)
/api/auth/callback/auth0
AWS CognitoAUTH_COGNITO_CLIENT_ID
AUTH_COGNITO_CLIENT_SECRET
AUTH_COGNITO_ISSUER

AUTH_COGNITO_ALLOW_ACCOUNT_LINKING=true (optional)
/api/auth/callback/cognito
Custom OAuth (source)AUTH_CUSTOM_CLIENT_ID
AUTH_CUSTOM_CLIENT_SECRET
AUTH_CUSTOM_ISSUER
AUTH_CUSTOM_NAME (any, used only in UI)

AUTH_CUSTOM_ALLOW_ACCOUNT_LINKING=true (optional)

AUTH_CUSTOM_SCOPE (optional, defaults to "openid email profile")
/api/auth/callback/custom

Use *_ALLOW_ACCOUNT_LINKING to allow merging accounts with the same email address. This is useful when users sign in with different providers or email/password but have the same email address. You need to be careful with this setting as it can lead to security issues if the emails are not verified.

Need another provider? Langfuse uses Auth.js, which integrates with many providers. Add a feature request on GitHub if you want us to add support for a specific provider.

Additional configuration

VariableDescription
AUTH_DOMAINS_WITH_SSO_ENFORCEMENTComma-separated list of domains that are only allowed to sign in using SSO. Email/password sign in is disabled for these domains. E.g. domain1.com,domain2.com
AUTH_DISABLE_SIGNUPSet to true to disable sign up for new users. Only existing users can sign in. This affects all new users that try to sign up, also those who received an invite to a project and have no account yet.
AUTH_SESSION_MAX_AGESet the maximum age of the session (JWT) in minutes. The default is 30 days (43200). The value must be greater than 5 minutes, as the front-end application refreshes its session every 5 minutes.

Headless Initialization

By default, you need to create a user account, organization and project via the Langfuse UI before being able to use the API. You can find the API keys in the project settings within the UI.

If you want to automatically initialize these resources, you can optionally use the following LANGFUSE_INIT_* environment variables. When these variables are set, Langfuse will automatically create the specified resources on startup if they don’t already exist. This allows for easy integration with infrastructure-as-code and automated deployment pipelines.

Environment VariableDescriptionRequired to Create ResourceExample
LANGFUSE_INIT_ORG_IDUnique identifier for the organizationYesmy-org
LANGFUSE_INIT_ORG_NAMEName of the organizationNoMy Org
LANGFUSE_INIT_PROJECT_IDUnique identifier for the projectYesmy-project
LANGFUSE_INIT_PROJECT_NAMEName of the projectNoMy Project
LANGFUSE_INIT_PROJECT_PUBLIC_KEYPublic API key for the projectYeslf_pk_1234567890
LANGFUSE_INIT_PROJECT_SECRET_KEYSecret API key for the projectYeslf_sk_1234567890
LANGFUSE_INIT_USER_EMAILEmail address of the initial userYesuser@example.com
LANGFUSE_INIT_USER_NAMEName of the initial userNoJohn Doe
LANGFUSE_INIT_USER_PASSWORDPassword for the initial userYespassword123

The different resources depend on each other in the following way. You can e.g. intialize an organization and a user wihtout having to also initialize a project and API keys, but you cannot initialize a project without also initializing an organization.

Organization
├── Project      (part of organization)
│   └── API Keys (set for project)
└── User         (owner of organization)

Troubleshooting:

  • If you use LANGFUSE_INIT_* in Docker Compose, do not double-quote the values (GitHub issue).
  • The resources depend on one another (see note above). For example, you must create an organization to initialize a project.

Configuring the Enterprise Edition

The Enterprise Edition (compare versions) of Langfuse includes additional optional configuration options that can be set via environment variables.

VariableDescription
LANGFUSE_ALLOWED_ORGANIZATION_CREATORSComma-separated list of allowlisted users that can create new organizations. By default, all users can create organizations. E.g. user1@langfuse.com,user2@langfuse.com.
LANGFUSE_UI_API_HOSTCustomize the hostname that is referenced in the settings. Defaults to window.origin.
LANGFUSE_UI_DOCUMENTATION_HREFCustomize the documentation link reference in the menu and settings.
LANGFUSE_UI_SUPPORT_HREFCustomize the support link reference in the menu and settings.
LANGFUSE_UI_FEEDBACK_HREFReplace the default feedback widget with your own feedback link.
LANGFUSE_UI_LOGO_DARK_MODE_HREF
LANGFUSE_UI_LOGO_LIGHT_MODE_HREF
Co-brand the Langfuse interface with your own logo. Langfuse adapts to the logo width, with a maximum aspect ratio of 1:3. Narrower ratios (e.g., 2:3, 1:1) also work. The logo is fitted into a bounding box, so there are no specific pixel constraints. For reference, the example logo is 160px x 400px.
LANGFUSE_UI_DEFAULT_MODEL_ADAPTERSet the default model adapter for the LLM playground and evals. Options: OpenAI, Anthropic, Azure. Example: Anthropic
LANGFUSE_UI_DEFAULT_BASE_URL_OPENAISet the default base URL for OpenAI API in the LLM playground and evals. Example: https://api.openai.com/v1
LANGFUSE_UI_DEFAULT_BASE_URL_ANTHROPICSet the default base URL for Anthropic API in the LLM playground and evals. Example: https://api.anthropic.com
LANGFUSE_UI_DEFAULT_BASE_URL_AZURE_OPENAISet the default base URL for Azure OpenAI API in the LLM playground and evals. Example: https://{instanceName}.openai.azure.com/openai/deployments

Health and Readiness Check Endpoint

Langfuse includes a health check endpoint at /api/public/health and a readiness check endpoint at /api/public/ready. The health check endpoint checks both API functionality and database connectivity and indicates if the application is alive. The readiness check endpoint indicates if the application is ready to serve traffic.

Access the health and readiness check endpoints:

curl http://localhost:3000/api/public/health
curl http://localhost:3000/api/public/ready

The potential responses from the health check endpoint are:

  • 200 OK: Both the API is functioning normally and a successful connection to the database was made.
  • 503 Service Unavailable: Either the API is not functioning or it couldn’t establish a connection to the database.

The potential responses from the readiness check endpoint are:

  • 200 OK: The application is ready to serve traffic.
  • 500 Internal Server Error: The application received a SIGTERM or SIGINT and should not receive traffic.

Applications and monitoring services can call this endpoint periodically for health updates.

HTTPS

For encryption in transit, HTTPS is strongly recommended. Langfuse itself does not handle HTTPS directly. Instead, HTTPS is typically managed at the infrastructure level. There are two main approaches to handle HTTPS for Langfuse:

  1. Load Balancer Termination: In this approach, HTTPS is terminated at the load balancer level. The load balancer handles the SSL/TLS certificates and encryption, then forwards the decrypted traffic to the Langfuse container over HTTP. This is a common and straightforward method, especially in cloud environments.

    • Pros: Simplifies certificate management as it is usually a fully managed service (e.g. AWS ALB), offloads encryption overhead from application servers.
    • Cons: Traffic between load balancer and Langfuse container is unencrypted (though typically within a secure network).
  2. Service Mesh Sidecar: This method involves using a service mesh like Istio or Linkerd. A sidecar proxy is deployed alongside each Langfuse container, handling all network traffic including HTTPS.

    • Pros: Provides end-to-end encryption (mutual TLS), offers advanced traffic management and observability.
    • Cons: Adds complexity to the deployment, requires understanding of service mesh concepts.

Once HTTPS is enabled, you can configure add LANGFUSE_CSP_ENFORCE_HTTPS=true to ensure browser only allow HTTPS connections when using Langfuse.

Build Langfuse from source

While we recommend using the prebuilt docker image, you can also build the image yourself from source.

The repo includes multiple Dockerfile files. You only need to build the web Dockerfile as shown below.

# clone repo
git clone https://github.com/langfuse/langfuse.git
cd langfuse
 
# checkout production branch
# main branch includes unreleased changes that might be unstable
git checkout production
 
# build image
docker build -t langfuse/langfuse -f ./web/Dockerfile .

Custom Base Path

If you want to deploy Langfuse behind a custom base path (e.g. https://yourdomain.com/langfuse), you can set the NEXT_PUBLIC_BASE_PATH environment variable. This is useful if you want to deploy Langfuse on a subpath, especially when integrating Langfuse into existing infrastructure.

As this base path is inlined in static assets, you cannot use the prebuilt docker image. You need to build the image from source with the NEXT_PUBLIC_BASE_PATH environment variable set at build time.

When using a custom base path, NEXTAUTH_URL must be set to the full URL including the base path and /api/auth. For example, if you are deploying Langfuse at https://yourdomain.com/langfuse-base-path, you need to set:

.env
NEXT_PUBLIC_BASE_PATH="/langfuse-base-path"
NEXTAUTH_URL="https://yourdomain.com/langfuse-base-path/api/auth"

Build image with NEXT_PUBLIC_BASE_PATH as build argument:

# clone repo
git clone https://github.com/langfuse/langfuse.git
cd langfuse
 
# use production branch
# main branch includes unreleased changes that might be unstable
git checkout production
 
# build image with NEXT_PUBLIC_BASE_PATH
docker build -t langfuse/langfuse --build-arg NEXT_PUBLIC_BASE_PATH=/langfuse-base-path -f ./web/Dockerfile .

Troubleshooting

If you encounter issues, ensure the following:

  • NEXTAUTH_URL exactly matches the URL you’re accessing Langfuse with. Pay attention to the protocol (http vs https) and the port (e.g., 3000 if you do not expose Langfuse on port 80).
  • Set HOSTNAME to 0.0.0.0 if you cannot access Langfuse.
  • SSO: Ensure that the OAuth provider is configured correctly. The return path needs to match the NEXTAUTH_URL, and the OAuth client needs to be configured with the correct callback URL.
  • Encode special characters in DATABASE_URL, see this StackOverflow answer for details.
  • If you use the SDKs to connect with Langfuse, use auth_check() to verify that the connection works.
  • Make sure you are at least on Postgres 12.
  • When using Docker Compose / Kubernetes, your application needs to connect to the Langfuse container at the docker internal network address that you specified, e.g. http://langfuse:3000/http://langfuse.docker.internal:3000. Learn more: docker compose networking documentation, kubernetes networking documentation

Updating the Application

We recommend enabling automated updates within the current major version to benefit from the latest features, bug fixes, and security patches.

To update the application:

  1. Stop the container.
  2. Pull the latest container.
  3. Restart the application.

During container startup, any necessary database migrations will be applied automatically if the database schema has changed. This can be optionally disabled via environment variables.

Langfuse is released through tagged semver releases. Check GitHub releases for information about the changes in each version.

Langfuse releases

Watch the repository on GitHub to get notified about new releases

(Optional) Apply newly supported models to existing data in Langfuse

This is only necessary if you want new model prices to be applied to existing traces/generations. Most users will not need to do this as applying prices to new traces only is totally fine when updating regularly.

Langfuse includes a list of supported models for usage and cost tracking. If a Langfuse update includes support for new models, these will only be applied to newly ingested traces/generations.

Optionally, you can apply the new model definitions to existing data using the following steps. During the migration, the database remains available (non-blocking).

  1. Clone the repository and create an .env file:

    # Clone the Langfuse repository
    git clone https://github.com/langfuse/langfuse.git
     
    # Navigate to the Langfuse directory
    cd langfuse
     
    # Install all dependencies
    pnpm i
     
    # Create an .env file
    cp .env.dev.example .env
  2. Edit the .env to connect to your database from your machine:

    .env
    NODE_ENV=production
     
    # Replace with your database connection string
    DATABASE_URL=postgresql://postgres:postgres@localhost:5432/postgres
  3. Execute the migration. Depending on the size of your database, this might take a while.

    pnpm run models:migrate
  4. Clean up: remove the .env file to avoid connecting to the production database from your local machine.

Kubernetes deployments

Kubernetes is a popular choice for deploying Langfuse when teams maintain the rest of their infrastructure using Kubernetes. You can find community-maintained templates and Helm Charts in the langfuse/langfuse-k8s repository.

If you encounter any bugs or have suggestions for improvements, please contribute to the repository by submitting issues or pull requests.

Platform-specific information

This section is work in progress and relies on community contributions. The Langfuse team/maintainers do not have the capacity to maintain or test this section. If you have successfully deployed Langfuse on a specific platform, consider contributing a guide either via a GitHub PR/Issue or by reaching out to the maintainers. Please also let us know if one of these guides does not work anymore or if you have a better solution.

Support

If you experience any issues, please join us on Discord or contact the maintainers at support@langfuse.com.

For support with production deployments, the Langfuse team provides dedicated enterprise support. To learn more, reach out to enterprise@langfuse.com or schedule a demo.

Alternatively, you may consider using Langfuse Cloud, which is a fully managed version of Langfuse. You can find information about its security and privacy here.

FAQ

GitHub Discussions

Was this page useful?

Questions? We're here to help

Subscribe to updates