The current Langfuse v4 self-hosted architecture uses Web and Worker containers plus PostgreSQL, ClickHouse, Redis/Valkey and S3/blob storage. As trace ingestion grows, bottlenecks often move to workers, ClickHouse or queue/storage layers rather than the web container.
Current Langfuse v4 uses Postgres for transactional state, ClickHouse for traces/observations/scores, Redis or Valkey for queues/cache and S3/blob storage for raw events, multimodal inputs and exports. Web accepts events quickly and workers process them asynchronously into ClickHouse.
SDK/API events reach the Web container, raw events are written to S3, references are queued in Redis and Workers process and batch-insert into ClickHouse.
Each storage component has different backup and scaling requirements.
Langfuse scaling guidance recommends horizontally scaling worker containers based on CPU load. Observe Web, Worker, ClickHouse and Redis saturation separately.
Adapt container names to your Compose/Kubernetes setup.
docker compose psdocker stats --no-streamdocker compose logs --tail=100 langfuse-workerdocker compose logs --tail=100 langfuse-webdf -hPostgres, ClickHouse and S3/blob data have different recovery mechanisms. Redis queue/cache durability depends on design. Test component compatibility before upgrades.
Web/Worker containers plus PostgreSQL, ClickHouse, Redis/Valkey and S3/blob storage form the core architecture.
Docker Compose can fit testing/low scale; official docs note it lacks production HA, scaling and backup capabilities.
It stores high-volume traces, observations and scores with high write throughput and analytical query performance.
Share daily traces/events, retention, multimodal files, worker count and HA needs; we can design Web/Worker/ClickHouse/Redis/S3.