09.09.2026 Problem:
A customer preparing to deploy Langfuse from an AWS Marketplace VM requested guidance for sizing, installation in a VPC, required network ports, and hardening. Their intended use was as a shared enterprise evaluation service for AI applications with about 500 million observability events (traces, spans/steps, evaluation scores). Integration requirements included Langfuse Python/JS SDKs, a REST API, an LLM gateway to an in‑VPC model runtime, OpenTelemetry OTLP over HTTP (protobuf or JSON), and Okta SSO (OIDC or SAML) plus SCIM provisioning. The customer asked which parts of the Marketplace image met these needs and what network/security controls to implement.
Observable configuration context: the Marketplace image available to the customer shipped Langfuse 2.17.0. The customer had not yet deployed but planned to ingest large volumes and use Bedrock-like in‑VPC model access and automated provisioning via SCIM. No runtime errors were present because the image had not been run, but risk signals included version age and feature gaps relative to the customer’s stated requirements.
Process:
Step 1: Verify published image and feature baseline
An investigation began by confirming the Marketplace VM’s packaged Langfuse version and comparing documented feature sets for that release against the customer’s list. Release notes and the image metadata were reviewed; this revealed the Marketplace VM contained a Langfuse 2.x build. This mattered because several recent ingestion and provisioning features were added in subsequent major releases, directly impacting the customer’s volume and integration expectations.
Step 2: Map requirements to storage and ingestion capabilities
Attention focused on the 500M-event scale requirement and ingestion protocols. The 2.x line’s storage design (transactional data and traces stored in Postgres) and the absence of an OTLP over HTTP ingestion endpoint were identified from release documentation. This discovery demonstrated that at scale the image would become a bottleneck and lacked the required collector endpoint, influencing the decision to avoid deploying that image for production.
Step 3: Check identity and provisioning support
Okta OIDC compatibility was verified for the older build, but SCIM provisioning was not present in the 2.x line. Review of authentication and provisioning capabilities clarified that enterprise provisioning and organization-level RBAC relied on later releases and an enterprise license. The lack of SCIM mattered because automated user lifecycle and group sync were explicit customer requirements.
Step 4: Validate model/gateway authentication semantics
Requirements for connecting to an in‑VPC model runtime without static keys prompted review of available auth options. The older image did not support role‑based credential chaining for model invocation; later Langfuse releases introduced AWS SDK default credential chain support. This discovery showed the Marketplace VM would force use of static credentials or insecure workarounds, raising a security and operational risk for the customer’s Bedrock integration plan.
Step 5: Produce a recommended architecture footprint
With feature mismatches established, a recommended architecture was drafted: current Langfuse release deployed as horizontally scalable web and async worker containers, Postgres for transactions, ClickHouse for traces/observations/scores, Redis/Valkey for ingestion queuing, and S3 for raw event/media. Network topology was sketched with a single external ingress (443 → TLS-terminated load balancer → web tier) and private subnets for all other services, plus VPC endpoints for the object store and the model runtime. This addressed both scale and security constraints identified earlier and guided the installation advice delivered to the customer.
Step 6: Deliver installation guidance and pause deployment
An installation guide and hardening checklist were assembled and provided. The guidance explicitly recommended postponing deployment of the Marketplace VM image until an updated image or container-based deployment matching the recommended architecture was available. This final step transitioned the investigation into the implemented change and led directly to the solution described below.
Solution:
The outcome was a change of plan: rather than deploying the Marketplace Langfuse 2.17.0 VM, the customer received a deployment and hardening recommendation to install a current Langfuse release using a distributed footprint inside the VPC — web + async worker containers, Postgres, ClickHouse, Redis/Valkey, and S3 with VPC endpoints — and to expose only HTTPS (443) via a TLS-terminating load balancer. Okta OIDC was used for SSO; SCIM and organization-level RBAC were documented as enterprise-license features to enable provisioning. For the model runtime, the recommendation used the cloud SDK default credential chain with a scoped IAM role so no static keys are required.
Architecturally, this fix works because the newer Langfuse releases use ClickHouse for high-volume observability data and provide OTLP over HTTP ingestion, addressing throughput and protocol requirements, while the containerized, multi‑component deployment allows horizontal scaling and keeps sensitive services private inside the VPC.
Conclusion:
Replacing the Marketplace VM plan with a current, containerized Langfuse deployment removed immediate scalability and feature risks, restored support for OTLP ingestion and role-based model access, and enabled a single ingress surface for hardened network controls. The change reduced the risk of ingestion bottlenecks and outdated security patches and provided a clear path to meet the customer’s enterprise provisioning and scale targets.