Running Langfuse self-hosted on Azure Container Apps with ClickHouse Cloud: viable in Production? Anything to be aware of?

[minialexd]

Describe your question

We're planning a self-hosted deployment and would appreciate a sanity check on the architecture before we build.

Context: We run a multi-customer SaaS on Azure with an AU data-residency requirement, so we're self-hosting. We are a small team, and we'd prefer not to run an AKS cluster for this, as everything else we operate is on Azure Container Apps.

Planned architecture:

• langfuse/langfuse (×2) and langfuse/langfuse-worker on Azure Container Apps
• Azure Database for PostgreSQL Flexible Server
• Azure Cache for Redis
• Azure Blob Storage
• ClickHouse Cloud as the external ClickHouse

We're asking because the self-hosting docs recommend Kubernetes (Helm) for production and don't list anything like Container Apps, so we want to understand whether that's a hard dependency or simply the documented path.

Questions:

• Is Container Apps a deployment target you'd consider sane for production, or do you know of reasons it falls over in practice? Basically is Kubernetes a hard requirement for production, or just the documented path?
• Is there any recommended patters or guidelines that you can point me towards for setting something like this up?

Thanks in advance for your help,

Langfuse Cloud or Self-Hosted?

Self-Hosted

If Self-Hosted

If Langfuse Cloud

SDK and integration versions

No response

Pre-Submission Checklist

• I have checked for existing issues/discussions and consulted Langfuse AI.

[inkeep-ai-assistant[bot]]

Your proposed architecture is reasonable for production. Kubernetes is the documented path, but it's not a hard requirement—Langfuse runs as standard containers (web and worker) that connect to external dependencies, so any container orchestrator capable of running Docker containers with the correct environment variables should work. (1)

Your planned stack looks solid:

• ClickHouse Cloud: This is explicitly recommended for larger deployments. ClickHouse Cloud separates storage from compute and supports compute-compute separation, which helps with scaling. (2)

• Azure Database for PostgreSQL Flexible Server: External PostgreSQL is supported—you just need to configure the connection via environment variables. (1)

• Azure Cache for Redis: External Redis is supported. If you're using Azure Cache for Redis in cluster mode, be aware that Langfuse supports Redis Cluster mode—configure it with the cluster nodes. (1)

• Azure Blob Storage: Azure Blob Storage is natively supported. Set storageProvider: "azure" and configure with your storage account name and key. (1)

Key configuration for Azure Blob Storage:

s3:
  deploy: false
  storageProvider: "azure"
  bucket: "langfuse"  # Container name
  accessKeyId:
    value: "yourstorageaccount"  # Azure Storage Account name
  secretAccessKey:
    value: "your-storage-account-key"  # Azure Storage Account key
  endpoint: "https://yourstorageaccount.blob.core.windows.net"

(1)

Key configuration for ClickHouse Cloud:

CLICKHOUSE_URL=https://<identifier>.<region>.aws.clickhouse.cloud:8443
CLICKHOUSE_MIGRATION_URL=clickhouse://<identifier>.<region>.aws.clickhouse.cloud:9440
CLICKHOUSE_USER=default
CLICKHOUSE_PASSWORD=changeme
CLICKHOUSE_MIGRATION_SSL=true

(2)

Things to be aware of:

1. ClickHouse Cloud on Azure: If using ClickHouse Cloud Azure, you may need to set CLICKHOUSE_CLUSTER_ENABLED=false due to how Azure handles ON CLUSTER and Replicated settings. (2)

2. Redis Cluster mode: If using Azure Cache for Redis in cluster mode, there's a known issue with CROSSSLOT errors causing prompt creation failures. (3)

3. Scaling the web/worker containers: For production, ensure adequate CPU and memory. The Helm chart recommends 2 CPU / 4Gi memory for Langfuse containers as a baseline. (1)

4. Private connectivity: ClickHouse Cloud offers private links for Azure if you need to keep traffic within your network boundary. (2)

The main reason Kubernetes is documented is that it's the most common production orchestrator and the Helm chart bundles all dependencies conveniently. Since you're using all external managed services (PostgreSQL, Redis, ClickHouse Cloud, Blob Storage), you're essentially just running the stateless Langfuse containers—Container Apps should handle that fine.

📚 Sources:

1. Kubernetes (Helm) (self-hosted) - Langfuse
2. ClickHouse
3. Scaling

---

Have another question? Just tag @inkeep.

[renezander030]

Container Apps is a sane target for this, the Helm docs describe the tested path rather than a runtime requirement, and the earlier reply covers that part. The two things I would pin down before building are both at the edges of your diagram. The langfuse-worker is a queue consumer with no inbound HTTP, and ACA defaults to scale to zero, so give it minReplicas 1 or ingestion stalls silently while the web containers look perfectly healthy. And your AU residency requirement travels with the traces, not just the app, so confirm ClickHouse Cloud can pin an Australian region reachable from your ACA environment before you commit, otherwise the observability layer ships customer prompts offshore while everything else stays compliant. Which region were you planning to run ClickHouse Cloud in?

[minialexd]

Thanks for the response René. Yep understood on both points - we are planning to use the clickhouse cloud ap-southeast-2 (Sydney) AWS public region; and also assessing the australia-southeast1(Sydney) private region; so this should suffice our compliance for Australian data residency. So we will likely go with this architecture then; I just wanted to confirm that it all sounds sensible - so thankyou.

One more question if you know it: the web container runs Postgres and ClickHouse migrations at startup. Is that safe with two replicas booting simultaneously (i.e. is there a migration lock), or is the safe pattern to roll out each release at one replica and scale back up?