Deploy Langfuse

Deploy and Host Langfuse V4 on Railway

For self-hosted LLM tracing and evaluation on Railway using Langfuse V4, use this Langfuse Pro Stack. It pins matching 4.59.0 web and worker images and connects PostgreSQL, ClickHouse, Redis and private S3-compatible storage. Administrator, organization, project and API keys are initialized at startup. Send V4-compatible observations from your applications; receiving traces does not require an OpenAI or Claude model key.

Langfuse, also searched as Lang Fuse, records model/agent observations, latency and supplied usage/cost metadata. Your administrator, organization, project and API keys are created at startup. No model key or custom domain is required.

Why Deploy Langfuse V4 on Railway?

First login and administrator email

1. Deploy with the default admin@example.com login, or set LANGFUSE_INIT_USER_EMAIL to your email before first startup.
2. Wait for the web, worker and databases to finish starting. Fresh migrations can take several minutes.
3. Open the Langfuse service's public HTTPS domain.
4. Sign in with LANGFUSE_INIT_USER_EMAIL and the unique LANGFUSE_INIT_USER_PASSWORD from Langfuse → Variables.
5. Open My Organization → My Project, or the names you chose in the initialization variables.

Public signup is disabled. admin@example.com is a placeholder login; it is not an accessible mailbox. Configure SMTP and a real email for recovery emails and invitations.

To add your own email after deployment, change LANGFUSE_INIT_USER_EMAIL and redeploy Langfuse. A new email creates another owner in the same organization, using the initialization password for that new account. It does not rename/delete the old account. Verify the new owner, keep the new email in the variable, then retire the original account through its settings if needed. Changing the password variable does not reset existing accounts.

Frequently asked questions

Does this template actually deploy Langfuse v4?

Yes. The web image is langfuse/langfuse:4.59.0 and the worker is langfuse/langfuse-worker:4.59.0. This is a fresh V4 stack with the observations-based data model. SDK/API compatibility matters when connecting applications that previously used V3.

Do I need OpenAI or Claude credentials to use Langfuse?

No model credentials are required to store and inspect traces. Your application sends telemetry with the generated Langfuse project keys. Instrumented OpenAI, Claude or other provider calls still use their own provider credentials in your application. Model-based evaluations may also need a configured model provider and incur provider charges.

Which SDKs work with this Langfuse V4 deployment?

The pinned 4.59.0 server supports Python SDK v5 and JS/TS SDK v6. Existing Python 4.7.0+ and JS/TS 5.4.0+ integrations are also V4-compatible. Consult the official compatibility matrix for runtime requirements and older integrations. For direct OTLP, send complete spans and x-langfuse-ingestion-version: 4.

Can I use Langfuse with LiteLLM, n8n or an agent framework?

Use an integration compatible with the V4 data model and OTLP ingestion. Current LiteLLM integrations use the langfuse_otel callback; configure the Langfuse host and project keys. For n8n, use a V4-compatible integration or an HTTP Request node sending complete OTLP JSON spans. Older nodes using legacy trace ingestion need updating. These applications are deployed separately.

Why are old trace ingestion examples failing?

Fresh self-hosted V4 deployments reject legacy trace/span/generation events via /api/public/ingestion and old synchronous trace endpoints. Use the OTLP endpoint below and the V4 observation APIs. This restriction concerns legacy trace ingestion; it is not a claim that every use of the batch endpoint, such as supported score ingestion, is removed.

Will traces and settings survive a restart?

Yes, with the same PostgreSQL, ClickHouse and Redis volumes and the same Bucket. Preserve stable secrets including SALT, ENCRYPTION_KEY and the shared web/worker configuration. Back up application metadata, observation storage and Bucket objects together before upgrades.

What does self-hosting Langfuse cost?

Railway hosting costs apply; some Langfuse features require edition-specific licensing. Configure retention if available in your edition and monitor storage growth. Backups and operations remain your responsibility.

Send a first trace without a model call

Use your service's HTTPS domain and generated LANGFUSE_INIT_PROJECT_PUBLIC_KEY / LANGFUSE_INIT_PROJECT_SECRET_KEY. Keep the secret key server-side. This standard-library Python example sends one completed observation without calling an LLM:

import base64, json, os, secrets, time, urllib.request

host = os.environ["LANGFUSE_HOST"].rstrip("/")
auth = os.environ["LANGFUSE_PUBLIC_KEY"] + ":" + os.environ["LANGFUSE_SECRET_KEY"]
trace_id = secrets.token_hex(16)
started = time.time_ns()
span = {
    "traceId": trace_id,
    "spanId": secrets.token_hex(8),
    "name": "railway-first-trace",
    "startTimeUnixNano": str(started),
    "endTimeUnixNano": str(started + 1_000_000),
    "attributes": [{"key": "langfuse.observation.input",
                    "value": {"stringValue": "Hello from Railway"}}],
}
request = urllib.request.Request(
    host + "/api/public/otel/v1/traces",
    data=json.dumps({"resourceSpans": [{"scopeSpans": [{"spans": [span]}]}]}).encode(),
    headers={"Authorization": "Basic " + base64.b64encode(auth.encode()).decode(),
             "Content-Type": "application/json",
             "x-langfuse-ingestion-version": "4"},
    method="POST",
)
with urllib.request.urlopen(request, timeout=30) as response:
    print("Ingestion accepted:", response.status)
print("Trace ID:", trace_id)

Look for railway-first-trace in your project's tracing view after a short processing delay. API acceptance confirms receipt; dashboard visibility confirms processing. Check programmatically with GET /api/public/v2/observations?traceId=YOUR_TRACE_ID using the same Basic authentication.

About Hosting Langfuse V4

Only Langfuse has a public domain. Services connect privately; the Bucket uses authenticated S3 and signed media/export URLs. Web and worker share storage/secret references. Standard database variables support Railway tooling.

Readiness, costs and operations

Startup checks use /api/public/ready on web, /api/health on worker and /ping on ClickHouse. Web readiness does not verify every dependency. You can check PostgreSQL through /api/public/health?failIfDatabaseUnavailable=true. Railway deployment health checks are not continuous monitoring; verify that a test observation reaches the dashboard.

The five services, three volumes and Bucket incur Railway charges even at idle. Web and worker each set a 3 GB Node.js heap ceiling, with additional runtime overhead. Measure memory, CPU, storage and ingestion delay with your workload; small tests do not establish production capacity.

Keep organization/project IDs and secrets stable. Headless initialization creates missing resources, not password resets or key rotations; manage those in Langfuse settings. After replacing Redis, let it become ready, then redeploy the worker if queue connections need refreshing. Queued jobs reside on Redis's volume.

Back up PostgreSQL, ClickHouse and Bucket data before upgrades; align web/worker versions and follow the migration guide. PostgreSQL stays on major 17 without a supported migration. Replicas and high availability need additional design.

Dependencies for Langfuse V4 Hosting

Deployment Dependencies

• Langfuse 4.59.0 release
• Self-hosted architecture
• Headless account and project initialization
• SDK and API compatibility
• OpenTelemetry integration
• LiteLLM integration
• Upgrade guidance

Your instrumentation determines which inputs, outputs, usage and costs are recorded.

Other deployment choices from this publisher

• For building AI applications rather than observing them: Dify
• For a separate chat workspace with a LiteLLM gateway: Open WebUI