Why is Langfuse's docker compose stack not a production self-hosted deployment?

## What the compose stack actually is The Langfuse repository includes a compose file that starts the application and every dependency: the **web** container, the **worker** container, **Postgres**, **ClickHouse**, **Redis** and **MinIO** standing in for S3-compatible object storage. It is genuinely useful. Someone can evaluate nested traces, prompt management and evaluators in minutes without provisioning anything, and it is the right first step before a self-hosting decision. The trap is treating it as a deployment template. It is a demonstration of the topology, not an implementation of it. ## What is missing **Single point of failure.** Every component is one process on one host with local volumes. Lose the host and you lose the application, the configuration database, the trace history and the object store at once. Nothing in the file replicates anything. **No backups.** Local volumes are not a backup strategy. Production needs a real backup for Postgres, which holds users, projects, API keys, prompt versions and dataset definitions, and a recovery plan for ClickHouse appropriate to the volume you are willing to lose. **Placeholder secrets.** `NEXTAUTH_SECRET`, `SALT` and `ENCRYPTION_KEY` come as example values so the stack starts. Shipping those to production means anyone with the public repository knows the values protecting your session layer, your hashed API keys, and the encryption of stored provider credentials. Generate real ones, for example `openssl rand -hex 32` for `ENCRYPTION_KEY`, and store them where you keep other secrets. Treat `ENCRYPTION_KEY` as unrecoverable: lose it and the secrets it protects become unreadable. **No TLS or exposure model.** The compose stack listens in plaintext and assumes a trusted local network. Production needs TLS termination, a real hostname in `NEXTAUTH_URL`, and a decision about who can reach the UI and the ingestion endpoint. **No capacity story.** One replica of each container, default resources, no scaling. A real ingestion load needs worker replicas sized to event volume and ClickHouse sized for the retention window. **Upgrades are downtime.** Bringing the stack down to pull new images is fine on a laptop. In production you want the stateless containers to roll while the stateful services stay up, which is a different deployment shape entirely. ## What production looks like instead The useful mental model: **keep the stateless part, outsource the stateful part.** The web and worker containers are stateless and horizontally scalable, so they belong wherever your team already runs services, commonly Kubernetes using the official Langfuse Helm chart, or plain containers on VMs behind a load balancer. Behind them, most teams point at managed services: managed Postgres, a managed or properly replicated ClickHouse, managed Redis or Valkey, and real S3 or an equivalent object store. That leaves you operating an application rather than a four-way stateful platform, while keeping every byte inside accounts you control, which was the point of self-hosting in the first place. Also carry over the operational details the compose file hides: run everything in UTC to avoid time ranges that disagree with the UI, monitor queue depth so a stalled worker is visible, set project retention deliberately, and back up Postgres first. ## How to answer it Do not just say "compose is not production". Name what is missing, in order of what would actually hurt: single host and no replication, no backups, example secrets, no TLS, no scaling, downtime upgrades. Then give the migration shape, stateless containers plus managed stateful services. That is the answer of someone who has run it rather than read about it.