Deploy and Host Langfuse v3 + ClickHouse on Railway

Self-host Langfuse v3, an open-source LLM observability platform, with Postgres, ClickHouse, Redis, MinIO object storage, a web service, and a worker service.

About Hosting Langfuse v3 on Railway

• web: public Langfuse UI/API service on port 3000
• worker: private background worker service on port 3030
• postgres: private transactional database
• clickhouse: private OLAP store for traces, observations, scores, and metrics
• redis: private cache and queue service with noeviction
• minio: S3-compatible object storage for event/media/batch-export blobs
• Generated secrets for auth, encryption, Postgres, ClickHouse, Redis, and MinIO

Why Deploy Langfuse v3 on Railway

Langfuse v3 is a production-shaped LLM observability stack, not a one-container demo. It uses the same major open-source components called out by the official self-hosting docs: Postgres for transactional state, ClickHouse for high-volume trace analytics, Redis for queues/cache, and blob storage for event and media payloads.

Common Use Cases

• LLM tracing and debugging
• Prompt-management experiments
• Evaluation and dataset workflows
• Open-source LangSmith alternative
• Internal observability for AI agents and LLM apps

Dependencies for Langfuse v3 Hosting

Langfuse requires Postgres, ClickHouse, Redis, object storage, a web app container, and a worker container. The template keeps Postgres, ClickHouse, Redis, and the worker private. MinIO is exposed only as an authenticated S3-compatible endpoint so browser-facing uploads can work.

Deployment Dependencies

• DATABASE_URL: private Postgres connection string
• CLICKHOUSE_URL and CLICKHOUSE_MIGRATION_URL: private ClickHouse HTTP/native URLs
• REDIS_HOST, REDIS_PORT, and REDIS_AUTH: private Redis queue/cache settings
• LANGFUSE_S3_*: MinIO-backed S3 event, media, and batch-export settings
• NEXTAUTH_SECRET, SALT, and ENCRYPTION_KEY: generated application secrets

After Deploy

1. Open the Langfuse public URL.
2. Sign in with the generated initial admin credentials.
3. Create or inspect the initial project and API keys.
4. Send a small SDK or OTLP test trace.
5. Confirm the trace appears in the UI after the worker processes it.

Support Checklist

If a deploy fails, include all service deployment IDs, /api/public/health, /api/public/ready, worker /api/health, and logs mentioning Postgres, ClickHouse, Redis, MinIO/S3, or migrations. The template intentionally avoids Railway healthcheck paths on the app containers so first-run migrations are not killed early.