Deploy and Host Langfuse v4 on Railway

Langfuse is open-source LLM engineering: tracing for every model call and agent step, prompt management with versioning, evaluations, and cost and latency analytics. Point any SDK or OpenTelemetry exporter at it and see what your AI application actually did, instead of guessing from application logs.

About Hosting Langfuse v4

Langfuse v4 rebuilt the storage layer: traces and observations that used to live in two joined tables are now one denormalised, append-only observations table, so table views and dashboards resolve without a join at query time. Everything else about self-hosting it stays the same shape — and that shape is six containers, not one.

This template wires them together: the web application, the background worker, PostgreSQL 17 for accounts, projects and prompts, ClickHouse 26.4 for the observation store, Valkey for the queue between web and worker, and S3-compatible object storage for event and media uploads. Credentials are generated per deployment, the services talk over the private network, and ClickHouse, Postgres, Valkey and the object store each get a volume.

Only the web service is published. Postgres, ClickHouse, Valkey and the object store stay private, reachable by the application and by nothing else.

Both SDK generations work out of the box. v4 defaults to an ingestion mode that rejects anything older than Python SDK 4.7 or JS/TS 5.4 — the legacy /api/public/ingestion endpoint answers 400 and the legacy read endpoints answer 404. This template ships LANGFUSE_MIGRATION_V4_WRITE_MODE=dual instead, so both the new OpenTelemetry path and every older SDK are accepted and readable. Set it to events_only once all your applications are on current SDKs: it halves what ClickHouse stores and is the mode Langfuse recommends long-term.

Common Use Cases

Debugging an agent in production: Follow one session through retrieval, tool calls and model responses, and see which step produced the answer you didn't expect.
Prompt management without redeploys: Version prompts centrally, roll them out and roll them back from the UI, with client-side caching so it costs no added latency.
Cost and quality tracking: Per-model, per-user and per-feature token spend next to evaluation scores, so a cheaper model's real cost in quality is visible before you switch.

Dependencies for Langfuse Hosting

Deployment Dependencies

Langfuse v4 — web and worker images, pinned to 4.14.0
PostgreSQL 17 — users, projects, prompts, datasets
ClickHouse 26.4 — observations and scores; v4 requires 25.12 or newer
Valkey 8.1 — queue between web and worker
S3-compatible object storage for event and media uploads
A Langfuse SDK or any OpenTelemetry exporter in your application

Implementation Details

Every image is pinned to an exact version. A floating tag like :4 or :latest means a redeploy months from now silently installs a different application than the one you tested — on a product that stores its data across two databases, that is not a risk worth taking for the convenience.

Valkey, not Redis, runs the queue. It takes a start command on Railway, so the queue is password-protected, runs with noeviction as BullMQ requires, and persists its append-only file to a volume — none of which a Redis image can be given here.

Every secret is generated per deployment: NEXTAUTH_SECRET, SALT, ENCRYPTION_KEY, the Postgres password, the Valkey password and the object-store root credentials. ENCRYPTION_KEY is what protects stored API keys and LLM credentials — losing it means losing access to them, so back it up before you rotate anything.

NEXTAUTH_URL is built from the public domain. It has to match the address you actually open, or sign-in redirects fail; if you attach a custom domain, update it.

The queue connection string carries ?family=6 — Railway's private network is IPv6-only, and the client has to be told to resolve AAAA records or it silently fails to connect.

The volume that grows is ClickHouse: it holds every observation. Set retention deliberately before the volume decides for you, and note that dual write mode stores each observation in both the old and the new layout until you switch to events_only.

Why Deploy Langfuse on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Langfuse on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Resources: six services is a real deployment, not a demo. Measured on an idle instance right after first boot: about 3.4 GB of memory in total, of which ClickHouse alone holds 1.4 GB and peaks near 2.9 GB during migrations. Budget on the order of $60–90 a month at low volume, and expect ClickHouse and your trace retention to drive it from there. If that is more than the workload justifies, Langfuse v3 remains supported with security patches into 2027 and runs noticeably lighter.