Self-hosted Arize alternative for EU data residency

Why EU teams look for a self-hosted Arize alternative for data residency

EU teams that trace LLM applications need to know where every trace, prompt and evaluation record is stored and processed, because those records can contain personal data from users, support tickets or documents. Self-hosted Langfuse, Opik or Phoenix can keep traces and prompts inside your own EU infrastructure, since you choose the cloud account, region and data centers. Arize AX's self-hosted option also keeps data in your environment, but it requires an Enterprise plan, so the commercial terms are part of the decision, not just the hosting location.

Residency is a property of where data is stored and processed, not a label a product carries. A hosted region can satisfy one part of that requirement while the surrounding flow still sends data elsewhere, for example through support access, billing records, telemetry or a control plane outside the region. Before choosing, map every place a trace, prompt, dataset or evaluation score is written, copied or read, including object storage, backups, logs and the model providers used by LLM-as-a-judge evaluators. Ask each vendor in writing which of those paths stay in-region.

The rest of this page separates what each option controls. Arize's EU data residency option, the Enterprise requirement for self-hosted AX, and the self-hosted footprint of Langfuse, Opik and Phoenix each leave different responsibilities with your team, and those differences affect your data protection assessment, your operations staff and your exit options. Confirm the current terms with the vendor, because residency commitments and plan entitlements change over time.

What an EU residency requirement asks of a tracing platform

An EU residency requirement reaches further than the database location. It also covers where data is processed, who can administer the platform, and how access and retention are enforced. The six cards below set out each requirement so you can test every candidate platform against the same questions.

Where trace and prompt data lives

Residency starts with the storage layer. Phoenix keeps traces, prompts and data in your infrastructure, including air-gapped deployments, but it starts with a file-based SQLite database by default, so plan a move to PostgreSQL for shared use. Self-hosted Langfuse spreads data across PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. Each of those locations must sit in an approved EU region, and backups and replicas must follow the same rule.

Where data is processed

Storage is only one part of residency. Ask which components process data and whether any of them call a vendor endpoint. Portkey's hybrid model keeps the gateway in your VPC, but its control plane runs in Portkey's VPC and the gateway calls out over HTTPS. LangSmith Cloud keeps trace data in the region where the account signed up, yet billing information stays in the US. Map every outbound call, telemetry setting and update channel before you accept a region claim.

Who can administer the platform

Residency also covers people with administrative reach. Operators with cluster access, database credentials or object storage keys can read stored data whatever the application's permissions say. Restrict those paths to named EU staff, record who holds them, and keep platform administrators separate from project users. Self-hosted Phoenix supports OAuth2, LDAP and local accounts with role-based permissions, so access can follow your existing directory. Confirm with your DPO which roles count as access to personal data.

Access controls and audit trails

Access control needs more than a login screen. Self-hosted Langfuse gates project-level RBAC roles, protected prompt labels, audit logs and server-side data masking behind an Enterprise license key, along with the org management API with SCIM. Check the gated list in writing before you commit, because a deployment without the key may not provide the audit trail your reviewer expects. Ask each vendor which controls are open source and which need a commercial key.

Retention and deletion rules

Retention decides how long personal data stays in the region. Langfuse lists data retention policies as an Enterprise key feature, so on a deployment without the key you need a deletion schedule you run yourself. Exports also create copies. LangSmith bulk export writes Parquet files to an S3-compatible bucket, and that bucket becomes a residency scope of its own. Decide which bucket holds exports, who can read it, and how a deletion request reaches backups and exported files.

Confirm in-scope data first

Before choosing a platform, agree with your DPO and counsel what counts as in-scope data. Trace payloads, prompt text, user identifiers, embeddings, evaluation judgments and human annotations can each carry personal data, and the answer decides which stores, regions and retention rules apply. Record the decision in a data map, then test each candidate against it. The same map should define the scope you request in any implementation quote.

What Arize AX's EU residency option does and does not cover

The supplied material does not describe Arize AX's EU region in enough detail to state its scope here, so treat any residency claim as something to confirm in writing before you rely on it. Ask Arize to specify which data classes are stored in the EU, including traces, span attributes, prompts, datasets, evaluation results, user feedback and any embeddings. Then ask where processing happens, whether support engineers can access tenant data and from which countries, and whether telemetry about your usage leaves the region. Ask for the sub-processor list, the regions each sub-processor operates in, where backups are kept and how long they are retained, and the retention settings that apply to each data class.

Arize AX also offers a self-hosted option that runs on Kubernetes in GCP, AWS, Azure, IBM Cloud, OpenShift or Rancher environments, as described in the Arize AX on-premise overview. Confirm with Arize that this option requires an Enterprise plan, what it costs to license, which components run in your cloud account, and whether any control plane or telemetry still reaches Arize's infrastructure. Request the self-hosted license terms in writing, including upgrade rights, support scope and any usage restrictions, because those terms decide whether a self-hosted deployment meets your residency and operating model.

Once the answers are in hand, compare them with the question you are actually solving. If the requirement is that trace data and prompts never leave infrastructure your organization controls, a managed EU region is a different control from self-hosting, and the written answers will show how far it goes. Open-source options such as Phoenix, which its self-hosting docs say keeps traces, prompts and data in your infrastructure, Langfuse and Opik can be placed in your EU cloud account or data center. Your privacy and security teams should record which option satisfies each data class and who is accountable for it.

Which open-source option keeps traces and prompts in-region

This table compares self-hosted Langfuse, Opik and Phoenix with self-hosted Arize AX on an Enterprise contract against an EU residency requirement. Read each row as a question to answer for your own environment: where the data lands, what the license allows, and what the deployment asks of your team. Most of the residency decision depends on which systems actually receive traces and prompts.

Option	How it keeps data in your infrastructure	Licensing	Trade-offs to check
Self-hosted Langfuse	Runs on your Kubernetes cluster or VM in the EU region you choose, with PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage under your control	MIT for core code; ee directories under a separate commercial license	Some features need an Enterprise license key; ClickHouse sizing drives storage and memory
Self-hosted Opik	Server, web app, tracing and prompt management deploy with Docker Compose or Helm into your environment, using ClickHouse, MySQL and Redis	Apache-2.0; full platform self-hostable without a commercial license	You size and operate ClickHouse, MySQL and Redis; confirm feature parity with your AX usage
Self-hosted Phoenix	Runs in your infrastructure with traces, prompts and data kept there, including air-gapped deployments per its self-hosting docs	Elastic License 2.0; source-available, not OSI open source, and no offering to third parties as a managed service	Defaults to SQLite; use PostgreSQL via PHOENIX_SQL_DATABASE_URL for production; confirm your legal team accepts ELv2
Self-hosted Arize AX on Enterprise	Kubernetes deployment in your chosen cloud or on-premises environment, such as GCP, AWS, Azure, IBM Cloud, OpenShift or Rancher	Commercial enterprise contract	Requires an Enterprise agreement; confirm with Arize which regions and support terms apply in writing
Gateways (LiteLLM, Portkey)	Only relevant if residency scope includes provider calls; a self-hosted gateway keeps request routing in your network	LiteLLM MIT except enterprise directory; Portkey gateway MIT	Portkey hybrid still calls control.portkey.ai over HTTPS, so review that path against your residency scope

Choosing Langfuse, Opik or Phoenix for an in-region deployment

Choose Langfuse when your reviewers expect SSO, role-based access control, audit logs and retention policies as a standard part of the platform. Langfuse's core is MIT licensed, but several controls are gated behind an enterprise license key, so the cost and the procurement step sit on the enterprise side rather than the code side.

Gated controls: Project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking and the SCIM-based org management API need an Enterprise license key.
Support tier: The self-hosted pricing page lists a custom-priced Self-Hosted Enterprise plan with a named support engineer, solutions architect access and a support SLA. Ask for the exact terms in writing.
Operating load: Expect PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage to be run by your team, so the control plane costs are mostly staff time.
Residency: Because the data lives in your cluster, your region choice is set by where you deploy, not by a vendor region list.
Confirm: Ask whether the SSO and audit features you need are in the open-source tier or the license key tier for your version.

Before committing, map each control in your compliance checklist to either the open-source feature set or the license key list.

How to deploy Langfuse in an EU region

This sequence takes an EU team from residency terms to a production Langfuse deployment in its own cloud account, with traces, prompts and storage kept in the chosen region and upgrades planned from the start.

Confirm data scope and residency terms
Your data protection officer and security lead list what enters tracing: prompts, completions, user identifiers, metadata and uploaded files. Ask Arize in writing what its EU residency option covers, which data and billing records stay in-region, and what it does not cover, so the self-hosted design fills any gap on purpose. The step is done when the data inventory and the residency decision are signed off and filed with the project record.
Choose the EU account and regions
Select the cloud account, EU region and availability zones where the Kubernetes cluster, PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage will run. Confirm that backups, logs and any managed service add-ons also stay in the EU, because Langfuse's data sits across several components. Your cloud team should record the region and account IDs in the architecture document. The step is done when every component has an approved location in writing.
Deploy Langfuse on Kubernetes
For production, deploy Langfuse with its Helm chart or Terraform-based modules, using the Langfuse self-hosting documentation for the AWS, Azure or GCP path you chose. Docker Compose on a single virtual machine is acceptable only for testing, because it does not provide high availability. The deployment runs Langfuse Web and Langfuse Worker alongside the data stores. The step is done when both application containers report healthy and the UI loads from an internal address.
Size the data stores and blob storage
Start from the minimums in the Langfuse scaling guide: 2 CPU and 4 GiB each for web, worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of ClickHouse memory for larger deployments. Plan ClickHouse disk for your expected trace volume and retention, and plan worker scaling on CPU load. Ask your cloud provider to confirm that managed equivalents meet the same minimums. The step is done when a load test at expected ingestion confirms the sizing.
Configure SSO and enterprise features
Connect your identity provider through the authentication and SSO settings in the Langfuse documentation, and restrict sign-up to your organization. Decide which features you need from the enterprise list, such as project-level RBAC, audit logs, data retention policies or server-side data masking, and confirm with Langfuse whether a license key is required for each one. Store the key in your secrets manager. The step is done when a test user signs in through SSO and the required enterprise features are confirmed active or formally deferred.
Repoint OpenTelemetry exporters and set retention
Change the OpenTelemetry or Langfuse SDK endpoint in your applications to the EU deployment, and move API keys to per-project credentials. Confirm in a staging environment that traces, prompts and scores land in the new project. Configure retention to match the decisions from the first step, and confirm that deletion requests reach every store, including blob storage. The step is done when a sample trace from each application appears in the EU instance and the retention setting is documented.
Plan upgrades and migrations
Updates within a major version are non-disruptive, and database migrations run automatically at startup, so keep a tested pipeline for them. Major upgrades follow their own guides. Before moving from v3 to v4, confirm ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later, and budget ClickHouse disk headroom of about 3x when backfilling historic data, as the upgrade guide advises. The step is done when a staging upgrade runs end to end and the runbook records backup and rollback steps.

Questions EU teams ask before hiring outside help

Does self-hosting Arize remove the need for a DPA with Arize?

Not by itself. Self-hosting changes where trace data is stored, but it does not change whether your vendor relationships create processing obligations. Confirm the position in writing with Arize before you assume a data processing agreement is unnecessary. Under GDPR Article 28, a processor relationship needs a contract, so the key question is whether Arize can reach your data at all in the self-hosted model, including through support access, license validation, telemetry or updates. Ask Arize what leaves your environment, who can access it and under what terms. Your cloud provider or hosting partner also counts as a processor if it can reach personal data in traces or prompts, so list every party in your data map. Ask your privacy or legal team to review the answers.

What drives the cost and effort of self-hosting an Arize alternative?

Most of the cost is infrastructure and people, and the software license is often the smallest line. The main components are:

Infrastructure: Kubernetes capacity, databases, object storage, backups and networking in your cloud or data center. Langfuse's scaling guide lists minimums of 2 CPU and 4 GiB each for web, worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of ClickHouse memory for larger deployments.
Retention: how many days of traces you keep sets ClickHouse disk size, which grows with trace volume.
Licensing: Phoenix and Opik self-host without license fees, while Langfuse enterprise features and any Arize AX contract carry their own terms.
Staff time: design, migration, upgrades, on-call and evaluator maintenance.

Design and migration are one-time costs. Infrastructure, upgrades and support recur. Ask every quote to price each component separately.

Can our platform team run a self-hosted LLM tracing platform alone?

Many teams can, provided they already operate Kubernetes or Docker and have people who can run stateful databases. The skills that matter most are PostgreSQL backup and restore testing, ClickHouse sizing and monitoring, object storage credential management and a disciplined upgrade process. Langfuse's v3 to v4 upgrade guide requires ClickHouse 25.12 or later, with 26.4 recommended, plus PostgreSQL 15 or later and Redis 7.0 or later. Langfuse documents Docker Compose on a single VM for testing without high availability, so production needs Kubernetes with Helm or Terraform. Phoenix starts on SQLite by default and supports PostgreSQL for a durable deployment. Check that one named person will own the platform after launch. If that person does not exist, a retainer or a handover within a fixed scope can cover the gap.

How long does a self-hosted EU residency migration take?

The timeline depends on scope, and DeployOpen agrees it in writing before work starts. No general duration applies, because the answer changes with the number of environments, the platform chosen, the volume of traces and evaluators to move, the identity integration and whether the network is air-gapped. A narrow scope, such as one platform on one cluster with a single trace source, takes less time than a multi-team rollout that backfills historical data. Langfuse's v3 to v4 guide advises about 3x ClickHouse disk headroom when backfilling historic data, which is a planning input that can extend the work. Ask for milestones covering environment build, identity integration, instrumentation changes, data cutover and sign-off, and name the owner on your side for each one.

What does the implementation work need from our team?

The work needs three things from your side. First, cloud or data center access: accounts or cluster access with rights to create namespaces, databases, storage buckets and network rules, plus your change approval process. Second, an identity provider contact: the person who owns your OIDC or SAML configuration, so groups and roles map correctly. Phoenix supports OAuth2, LDAP and local accounts with role-based permissions, which gives you alternatives if SSO is not yet ready. Third, named data owners who decide retention periods, classify which prompt and trace fields are personal data and approve migrated datasets. The team should also list every application and SDK that sends traces and provide a representative evaluation sample. Record access rights and agree them in the written scope.

Which self-hosted option fits an EU residency requirement best?

It depends on which data must stay in region and which features you need. Phoenix's self-hosting docs say traces, prompts and data stay in your infrastructure, including air-gapped deployments, and that self-hosting carries no license fees or feature limits. Its Elastic License 2.0 bars offering Phoenix to third parties as a hosted service, which matters if you plan to resell it. Langfuse keeps its core under MIT, but RBAC, audit logs, data retention policies and SCIM need an enterprise license key. Opik is Apache-2.0 and its README says the full platform can be self-hosted without a commercial license. Note that LangSmith Cloud keeps trace data in the region where the account signed up, while billing information stays in the US, so check billing data handling separately.

Does DeployOpen issue GDPR or ISO compliance certification?

No. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. DeployOpen plans and implements the self-hosted platform, prepares systems, controls and evidence for compliance assessments, and can document configuration so your auditor has material to test. Ask your auditor or certification body which evidence it will accept for the controls it will test, and how it wants that evidence presented. Then define the deliverables in the written scope, such as configuration baselines, runbooks, access records and backup test results, so you know what the engagement hands over.

Evidence EU regulators and auditors ask for

Regulators and auditors rarely accept a residency claim on its own. They ask where traces and prompts are stored and processed, who can reach them, how long they live and how the platform is kept running. The cards below list the records that answer those questions for a self-hosted tracing stack. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any opinion.

Data flow diagrams

Map where trace payloads, prompts, metadata and exports are written and read: the application, the collector, the database, object storage and any SDK or gateway that sends data out. Mark every storage location with its region and account. Check whether any component calls a vendor endpoint for telemetry, licensing or updates, since a self-hosted platform can still make outbound calls. For Langfuse, the stores include PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage.

Sub-processor and vendor terms

If you self-host, the platform vendor is usually not a processor of your trace data, but any hosted add-on, managed database, support session or SaaS license check may be. List each one, its role, its data location and the contract that covers it. Ask the vendor in writing whether any support access to your deployment is possible and under what conditions. Keep this list next to the data flow diagram so the two stay consistent.

Access and identity configuration records

Export the role assignments, SSO settings and local account lists from the platform, then record who approved each role. Phoenix documents OAuth2, LDAP and local accounts with role-based permissions. Langfuse keeps project-level RBAC, audit logs and SCIM provisioning behind an Enterprise license key, so confirm that key is in place before you cite those controls. Save the configuration as a dated snapshot.

Audit logs and retention settings

Show that access and configuration changes are logged and that the logs are retained. Document the retention period for traces, prompts and evaluation results as a written setting, not a default you assume. Langfuse lists data retention policies and audit logs as Enterprise license features, so confirm their availability on your version. Test a deletion and keep the record that shows the data is gone from the database and object storage.

Backup and restore test records

Keep the backup schedule, the storage location of each backup, and the encryption setting for backup media. Most important, keep the result of a restore test into a separate environment that shows which databases were recovered and how long recovery took. A backup that has never been restored is weak evidence. Repeat the test after each major schema or storage change, such as a ClickHouse upgrade.

Upgrade and patch logs

Record each version deployed, the date, the change ticket and the test evidence. Langfuse applies database migrations automatically at startup within a major version, and major upgrades follow separate guides with their own prerequisites, so note the migration output for each change. Keep the advisory or release notes you reviewed before patching. Auditors look for a repeatable cycle, not a single clean update.

What moving EU traces and prompts involves

The work after deployment starts with instrumentation. Arize's OpenInference and OpenTelemetry instrumentation works with both Phoenix and Arize AX, so teams on Arize's standards may only need to repoint the exporter endpoint and credentials. Langfuse and Opik also accept OpenTelemetry, but attribute names, token fields and span hierarchies can differ, so confirm the attribute mapping in a staging project before cutover. Run the in-region instance alongside production for a representative period and compare span counts, latency fields and cost attributes. Also check which services send traces, because a forgotten batch job or evaluation script often keeps writing to the old region.

Historic data is the decision that needs the most care. Traces created before cutover stay in Arize's region unless you export them, so list which data your EU obligations, audits and regression tests actually require in-region. Where your Arize contract and terms allow, export traces, datasets and experiments with Arize's client, then reshape the output before loading it into the new platform. Ask Arize to confirm those export terms in writing for your plan. Prompts, dataset items and evaluator definitions must be recreated as new versions, with labels, and you should keep a mapping table so that old trace IDs still point to the correct prompt version. The sibling topics on migrating from Arize to Langfuse and exporting data from Arize cover the mechanics in detail.

Plan storage before you import anything. The Langfuse v3 to v4 upgrade guide advises about 3x ClickHouse disk headroom when backfilling historic data, and it requires ClickHouse 25.12 or later, with 26.4 recommended. Estimate the volume of history you plan to move, multiply it by that headroom, and size the volume before the first import. Rebuild LLM-as-a-judge evaluators and check which judge model they call, because a judge hosted outside the EU would undo the residency goal. Finally, ask your vendors and integrators to document where each data type sits, including backups, logs and any hosted evaluation service, so the residency claim covers the whole pipeline.

How DeployOpen deploys tracing inside your EU boundary

DeployOpen plans, implements and hardens self-hosted tracing platforms inside your own cloud accounts, data centers or networks, so traces, prompts and evaluation data stay in the EU boundary you define. The work is scoped in writing first, then built, documented and handed over to your team.

How we scope

Map which trace, prompt and evaluation data is in scope and where it must reside in the EU
Confirm which regions, accounts and subprocessors your residency rules cover, including support access
Agree in writing which platform, storage backends and integrations are included before work starts

How we build

Deploy the chosen platform, such as Langfuse, Opik or Phoenix, on Kubernetes or Docker Compose in your EU environment
Configure PostgreSQL, ClickHouse or Redis and object storage in-region, with backups and access controls
Test ingestion, retention and data masking settings against your residency and access requirements

How we hand over

Document architecture, data flows, network egress and the location of every stored data type
Provide runbooks for upgrades, database migrations and backup restores aligned to the vendor's guides
Deliver evidence that supports your compliance assessment, while independent auditors issue any formal opinion

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover
Review platform releases and plan upgrades, including major version migrations, under the agreed scope
Ask your vendor or the platform documentation to confirm any residency or licensing detail before go-live