Which Arize alternative works in an air-gapped network
If your traces, prompts and evaluation data cannot leave an enclosed network, the first filter is simple: only self-hosted tools that run without outbound calls qualify. Phoenix is the strongest fit on the supplied evidence, because its self-hosting documentation says it is free to self-host with no feature limitations, no license fees and no usage limits, and that data stays in your infrastructure, including air-gapped deployments. Langfuse and Opik can also be self-hosted in an isolated network, but each brings its own stack of databases and storage that you must deploy and keep inside the enclosure. Self-hosted Arize AX is a different case: Arize documents an on-premise option on Kubernetes, but it sits within an Enterprise commercial arrangement, so you should confirm in writing that it supports offline installation and updates before you rely on it.
The constraint is about data egress and external calls, not only inbound internet access. An air-gapped tracing stack can still fail the requirement if a component phones home for license validation, telemetry, model downloads or update checks. Ask each vendor to list every outbound destination its images, SDKs and evaluator configuration contact at runtime. For Phoenix, check the configuration and telemetry settings in the Phoenix self-hosting documentation and test with egress blocked. Also trace where LLM-as-a-judge evaluators send their prompts: if the judge model is a hosted API, your evaluation data leaves the enclosure even when the tracing server does not, so plan an in-enclosure model endpoint for every evaluator.
What an air-gapped LLM tracing stack must do without internet access
An air-gapped tracing stack has to work with no route to vendor control planes, license servers or public registries. The four requirements below connect the network rules, the image supply chain, evaluator models and upgrade path, and each one should be tested in your own environment before you commit to a platform.
No outbound calls to vendors
Confirm that every component, including the tracing server, workers, UI and telemetry SDKs, starts and runs with no outbound route to the vendor. The hybrid models need the closest review: Portkey's hybrid deployment keeps the gateway in your VPC but calls out over HTTPS to control.portkey.ai, and LangSmith's self-hosted deployment requires a license key that your environment must validate. Ask each vendor which hosts, if any, the software contacts during startup, license checks and telemetry, and block those hosts in a test network before rollout.
License keys that work offline
Identify which features depend on a license key and whether the key can be validated without a call to a license server. Self-hosted Langfuse needs an Enterprise license key for features such as audit logs, SCIM and data retention policies, and Phoenix is free to self-host with no feature limits. Opik's README states the full platform can be self-hosted without a commercial license. Ask for written confirmation of how each key is checked, how it is renewed, and what happens when it expires on a disconnected network.
Mirrored images and Helm charts
Every container image, Helm chart and dependency, including ClickHouse, PostgreSQL, Redis or Valkey and the Opik MySQL database, must be pulled once on a connected side, scanned, and pushed into an internal registry. Pin image tags and digests rather than floating tags so that a rebuild on the disconnected side produces the same artifacts. Keep a manifest of every image version and chart version in the bundle, so that the offline copy matches what was tested.
Evaluator models on internal endpoints
LLM-as-a-judge evaluations need a model to call. On an air-gapped network that model must be an internal endpoint, such as a self-hosted open-weight model behind your own gateway, or a model hosted in a private cloud boundary you control. Confirm which evaluators in your chosen platform accept a custom base URL, how they handle authentication, and whether their prompt templates ship with external dependencies. Test each evaluator end to end with the internal model before relying on its scores.
Offline upgrades from internal artifacts
Upgrades on a disconnected network depend on artifacts you can carry across the boundary, including release notes, chart packages, images and any database migration steps. Langfuse applies migrations automatically at startup within a major version, but its v3 to v4 guide requires ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later, and advises about 3x ClickHouse disk headroom when backfilling data. Plan each major upgrade as a dated change with a rollback snapshot, and check the release pages before you transfer artifacts.
How Arize AX, Phoenix, Langfuse and Opik meet the air-gapped constraint
This table compares four ways to run LLM tracing and evaluation with no internet access, covering licensing, required components and what still needs offline confirmation. Read each row against your own air-gapped build, since a licensing fit does not prove that every feature works without outbound connections.
| Option | Air-gapped fit and licensing | Components to run offline | Confirm before committing |
|---|---|---|---|
| Self-hosted Arize AX on Kubernetes | Self-hosted option under an Enterprise contract, supported on GCP, AWS, Azure, IBM Cloud, OpenShift or Rancher environments | Kubernetes cluster in the target environment, with the vendor's packaged deployment | Whether your Enterprise contract covers an offline install, and who delivers and verifies images and upgrades |
| Arize Phoenix | Free to self-host with no feature limits or usage caps, and its docs say this includes air-gapped deployments; licensed under ELv2, which is source-available rather than OSI open source | Default SQLite, or PostgreSQL via PHOENIX_SQL_DATABASE_URL; Docker, Kubernetes or Helm | ELv2 terms for your use case, and whether OAuth2, LDAP or local accounts meet your identity rules without outbound calls |
| Langfuse | MIT core; code in the ee directories falls under a separate enterprise license, and some advanced features need an enterprise license key | Langfuse Web, Langfuse Worker, PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible storage | Which required features, such as audit logs, RBAC and data masking, need the key, and how the key is validated in a disconnected network |
| Opik | Apache-2.0 licensed; the README states the full platform, including server, UI, evaluations and prompt management, can be self-hosted without a commercial license | ClickHouse, MySQL and Redis; Docker Compose for local use or Helm charts on Kubernetes for production | Offline behavior of LLM-as-a-judge metrics and Guardrails, and where evaluator models run and how they are reached |
Why the ELv2 license on Phoenix matters inside a closed network
The Elastic License 2.0 that covers Arize Phoenix permits you to self-host the software for your own internal use, which is the normal pattern in an air-gapped network. The two restrictions that matter here are that you may not provide Phoenix to third parties as a hosted or managed service, and you may not circumvent license key functionality. A bank or agency running Phoenix on its own hardware for its own analysts, engineers and data scientists is generally in the permitted pattern. The point to confirm with counsel is whether the deployment ever serves people outside your organization, such as a managed service for a business unit that is legally separate, a subsidiary, a contractor operating the instance for several clients, or a partner portal. Any of those can move the arrangement into the restricted category.
Before you rely on this, write down who will log in, who operates the instance and who pays for it. Confirm with Arize's license text and your counsel how the terms apply to your corporate structure. The Phoenix LICENSE file is the controlling text, and a short legal review costs far less than retrofitting a deployment after a contractor or affiliate starts using it. Keep the license file and your internal-use decision in the same change record as the deployment design, so auditors and procurement can see the basis for the decision.
The contrast with other options is useful but should not be overstated. Langfuse's core code outside its enterprise directories is MIT licensed, and Opik is Apache-2.0 licensed with its server, interface, evaluations and prompt management described as self-hostable without a commercial license. Both are OSI-approved open-source licenses, so a managed-service arrangement is not restricted by the license terms in the same way. Those licenses still carry their own conditions, and Langfuse's enterprise directories and enterprise license key features have separate terms. If your plan depends on a third party operating the stack, get a written license reading for each component you choose rather than assuming any one license covers everything.
How to deploy tracing offline, step by step
This sequence takes a team from choosing a tracing option to a tested, offline deployment inside an enclave with no internet egress, plus a documented path for upgrading it later.
Choose the option and confirm feature needs
Your architecture, security and platform leads pick one option, usually Phoenix, Langfuse or Opik, and list the features the enclave must support, such as OAuth2, LDAP or SSO, role-based access, data retention, audit logs and evaluation methods. Check each requirement against the vendor's self-hosting docs and license terms, because some Langfuse features need an enterprise license key and Phoenix is licensed under the Elastic License 2.0. The step is done when you have a written feature list, a license position signed off by legal, and a named owner for each component. Confirm any gap with the vendor before you build anything.
Build an internal artifact store for images and charts
The platform team mirrors every container image, Helm chart and Terraform module the deployment needs into a registry and chart repository inside the enclave, using an approved transfer process. For Phoenix, this means the Docker image or Helm chart; for Langfuse, its Helm chart and the images for Web, Worker, PostgreSQL, ClickHouse and Redis or Valkey; for Opik, its Helm charts and the ClickHouse, MySQL and Redis images. Record each image by version and digest in a manifest that your change process controls. The step is done when a node in the enclave can pull every image and render every chart with no external registry reachable.
Provision PostgreSQL, ClickHouse, Redis and blob storage
The infrastructure team stands up the data services inside the enclave. Phoenix can start on SQLite, but production use typically moves to PostgreSQL through PHOENIX_SQL_DATABASE_URL. Langfuse needs PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, and its scaling guide lists minimum resources of 2 CPU and 4 GiB 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. Opik uses ClickHouse, MySQL and Redis. Size storage for your retention needs and check the Langfuse v4 requirements of ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later. The step is done when every service passes a connectivity test from the application namespace and backups have been run once.
Deploy the tracing platform on Kubernetes
The platform team installs the chosen tool with its Helm chart or, for Phoenix, a Docker image on a single host for evaluation. Langfuse documents Docker Compose on a single VM for testing with no high availability, so use Kubernetes with Helm or Terraform for production. Opik provides Docker Compose through its opik.sh script for local use and Helm charts for production. Pin image versions from your mirror and store values files in version control. The step is done when the application pods report ready, the UI loads from inside the enclave and a test project appears.
Point OpenTelemetry and OpenInference exporters internally
Application teams change their exporters to send traces to the internal endpoint instead of any hosted service. Phoenix and Arize AX share OpenTelemetry and OpenInference instrumentation, so existing span code often needs only an endpoint and key change. Langfuse accepts OpenTelemetry traces, and Opik supports OpenTelemetry alongside its own SDK and the @track decorator. Remove or block any SDK default that points to a public host. The step is done when a sample request from each application produces a trace in the internal UI and the exporter logs show no outbound destinations.
Configure authentication and load evaluator models
The identity team connects the platform to OAuth2, LDAP or your SSO provider, following the authentication guidance for the chosen tool. Phoenix supports OAuth2, LDAP and local accounts with role-based permissions. Check which Langfuse roles and SCIM provisioning need an enterprise license key before you promise them to auditors. For LLM-as-a-judge evaluations, configure evaluator models to call endpoints inside the enclave, such as a self-hosted model server, and confirm each evaluator template resolves to that address. The step is done when a test user signs in through the identity provider and an evaluation run completes with no request leaving the network.
Test with network egress blocked
The security team runs a scripted test with outbound internet access blocked at the firewall and proxy, then exercises ingestion, the UI, login, exports, evaluations and any background jobs. Capture DNS and egress logs during the run and confirm no connection attempts reach public addresses, including telemetry or update checks. Record which failures occur so you can fix them. The step is done when the test runs clean from start to finish and the logs are attached to the deployment record for your assessors.
Document and rehearse the offline upgrade path
The platform team writes the upgrade runbook: how new images and charts are approved, transferred and mirrored, and how backups are taken before changes. Langfuse says updates within a major version are non-disruptive and run database migrations at startup, while major upgrades follow dedicated migration guides. The v3 to v4 guide calls for ClickHouse 25.12 or later (26.4 recommended) and advises about 3x ClickHouse disk headroom when backfilling historic data, so plan that storage before you start. Rehearse one upgrade in a staging enclave. The step is done when the runbook is approved and a rehearsal restores from backup successfully.
Evaluator models, upgrades and dependencies to plan offline
An air-gapped deployment moves the work that a vendor or cloud service normally absorbs onto your team: a model for LLM-as-a-judge scoring, mirrored images, version upgrades and licensing checks. The cards below cover the operational risks that connect these tasks, and what to confirm with each vendor before you commit to a design.
Evaluator model must sit inside the network
LLM-as-a-judge evaluators, such as Opik's hallucination, moderation and RAG metrics or Langfuse's LLM-as-a-judge evaluators, call a language model to score traces. Inside an air-gapped network, that judge model must be reachable from the evaluation workers, either as an internally hosted open-weight model or as an approved internal endpoint. Confirm with each vendor which evaluator templates accept a custom or OpenAI-compatible base URL, and whether any template silently calls a hosted model.
Image and chart updates need re-mirroring
Every release of the tracing platform, its database images and its Helm charts must be pulled on a connected host, scanned, transferred across the boundary and pushed to your internal registry. Record the exact image digests and chart versions you approve, so an upgrade is a controlled transfer rather than an ad hoc pull. Ask each vendor for the complete list of images a release needs, including sidecars and migration jobs.
Frequent Phoenix and Opik releases
Phoenix and Opik publish new releases very often. For example, Phoenix v20.23.0 was published on October 16, 2026, and Opik release 2.2.103 on the same day, with Phoenix shipping multiple releases per week. Budget a regular re-mirroring cycle, decide which versions you pin, and confirm with each vendor how long older versions remain compatible with the current database schema and client SDKs.
Langfuse ClickHouse and PostgreSQL staging
Langfuse depends on PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, and its major upgrades require specific minimum versions. The v3 to v4 guide calls for ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later, and advises about 3x ClickHouse disk headroom when backfilling historic data. Stage these upgrades in a non-production copy first, and confirm with Langfuse which dependency versions each release supports.
License keys and SSO without callbacks
Some enterprise features, such as Langfuse's project-level RBAC, audit logs and SCIM provisioning, need a license key, and identity federation depends on a reachable identity provider. Test in the isolated network that the license key validates without outbound calls, that SSO works against your internal identity provider, and that certificate or JWKS refresh does not depend on an internet endpoint. Ask each vendor whether license validation works offline and how a key is renewed.
Upgrade rehearsal and rollback plan
Updates within a major version apply database migrations automatically at startup, so a failed upgrade can leave the schema changed. Before each upgrade in the isolated network, take backups of PostgreSQL, ClickHouse and object storage, rehearse the upgrade on a copy, and document how to roll back an application image. Confirm with each vendor whether a rollback to the previous version is supported after a migration has run.
Questions buyers ask before an air-gapped rollout
What does an air-gapped LLM tracing rollout cost, and what drives the price?
The cost splits into one-time work and recurring running costs. One-time work covers architecture, installation, offline image handling, identity integration, hardening and handover. Recurring costs cover infrastructure, storage, upgrades and any support tier you buy. Infrastructure and storage scale with trace volume and retention. For Arize AX, the self-hosted option is part of an Enterprise contract, so ask Arize for its written license terms. For Phoenix, the software is free to self-host with no license fees, so your costs are infrastructure, staff time and any services partner you hire. For Langfuse, the core features are MIT licensed, but some advanced features need an enterprise license key and a support tier is priced separately. Ask any vendor or partner for line items, a written scope and the support tier included.
How long does an air-gapped deployment take, and what changes the timeline?
The timeline depends on your environment more than on the tool. The main variables are how many clusters you have, whether you run PostgreSQL, ClickHouse, Redis or Valkey and object storage yourself or reuse existing services, how quickly your security team approves the image transfer process, and how many identity integrations you need. Langfuse's production path expects Kubernetes with Helm or Terraform, and its scaling guide lists minimum resources for each component, which affects how much capacity you must provision first. Phoenix can start from a single process with SQLite, but a shared deployment usually moves to PostgreSQL. Ask for a milestone plan in the written scope that names your approval gates, rather than accepting a generic duration.
What must our team provide before the work starts?
Expect to provide a short list of access and infrastructure items before installation begins:
- A Kubernetes cluster with storage classes, ingress and the resources the chosen tool documents.
- An internal container and chart registry that holds every image, Helm chart and dependency, since nothing can be pulled from the internet.
- Storage for databases and blobs, such as PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, or agreed alternatives.
- Identity integration details for SSO or directory login, such as OAuth2, LDAP or SAML, depending on the product.
- Network rules that allow your applications to send traces and allow administrators to reach the UI, with no outbound calls.
Also name the people who approve image transfers and key handling. Ask DeployOpen or any other partner to list every artifact in the bill of materials before the transfer.
Can our own platform team run an air-gapped LLM tracing stack without outside help?
Often yes, if your team already runs Kubernetes, databases and internal registries. Phoenix self-hosts with terminal, Docker, Kubernetes or Helm options and supports local accounts and OAuth2 or LDAP, so a small team can start with a limited pilot. Langfuse and Opik have more moving parts, including ClickHouse and, for Langfuse, Redis or Valkey and blob storage, so operating them well requires database and observability skills. The harder work is ongoing: monitoring, backups, capacity growth and offline upgrades. Ask whether you need an outside team for the initial build, for hardening, or for recurring support, and which of those your staff can own. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms in your own environment, under a fixed written scope or a retainer.
Should we choose Arize AX Enterprise self-hosting or Phoenix for an air-gapped network?
Choose by licensing and feature need, not only by install effort. Arize AX documents a self-hosted option on Kubernetes in several cloud and on-premise environments, but it is tied to an Enterprise contract, so the cost and terms are negotiated. Phoenix is licensed under the Elastic License 2.0, which is source-available rather than OSI open source. Its documentation says it is free to self-host with no feature limits, and that data stays in your infrastructure, including air-gapped deployments. The ELv2 license bars offering Phoenix to third parties as a hosted or managed service, which does not affect internal air-gapped use. If you need an OSI-licensed option, Langfuse core and Opik under Apache-2.0 are candidates. Ask Arize for the written self-hosting terms and check your legal team's view of ELv2 before you commit.
How do we upgrade an air-gapped tracing platform without internet access?
Plan upgrades as a bundle transfer, not a pull. Each release needs its images, Helm charts and migration notes brought across your approved transfer process and loaded into your internal registry. Langfuse says updates within a major version are non-disruptive and run database migrations automatically at startup, while major upgrades follow dedicated guides. Its v3 to v4 guide requires ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later, and advises about 3x ClickHouse disk headroom when backfilling historic data. Phoenix and Opik release frequently, so set a version policy and test each bundle in a staging cluster before production. Take database backups before every upgrade and confirm rollback steps in the written scope.
Who handles evaluator models and LLM-as-a-judge calls when the network is closed?
This is a scope question you must settle early. Tracing and storage work fully offline, but LLM-based evaluations call a model, so the judge model must be reachable from inside your network. Options include a model served on your own hardware behind an internal endpoint, or an approved model endpoint inside your cloud boundary. Each evaluator and its model weights must be transferred and approved like any other artifact. Opik documents LLM-as-a-judge metrics for hallucination, moderation and RAG, and Phoenix and Langfuse also offer LLM-based evaluations, so confirm which judge providers each product supports with an offline endpoint. Ask for the evaluator inventory and the model hosting plan in the quote.
Evidence assessors ask for under an air-gapped control set
An air-gapped LLM tracing stack is judged on what it cannot reach and on whether that can be shown. The six items below are the records that connect the network boundary, the software inventory, the configuration and the operating history, so an assessor can test each claim without relying on the team's word. DeployOpen prepares this evidence, but auditors and certification bodies are the ones who issue opinions.
Network diagrams showing the egress block
Draw the trace path from application to collector to storage, then mark every boundary where traffic could leave the enclosure. Show the deny rules on the firewall or egress proxy, and show which internal addresses the tracing services use. For Phoenix, Langfuse or Opik, list each outbound destination the stack is expected to need during install and runtime, and confirm that none is public. Ask the vendor whether any component calls home by default, and record the answer in the diagram notes.
Mirrored artifact inventory with versions
List every container image, Helm chart, Python or Node package, and evaluator model that was copied into the internal registry, with its exact version and digest. For Langfuse, that covers the web and worker images plus PostgreSQL, ClickHouse, Redis or Valkey and object storage. For Phoenix, it covers the image and its database. Record where each artifact came from, when it was transferred and who checked its signature. An assessor will compare this list against the running cluster, so any drift will show.
Configuration records for disabled telemetry
Keep the configuration files, environment variables and Helm values that turn off outbound features, such as update checks, usage reporting and external model calls. Capture the values in version control with the commit that set them. Test the setting after each change by checking that the blocked connection attempts appear in the firewall logs as denied. Where a platform offers a feature that needs its own license key, record that the key is installed offline and which features it unlocks.
Access control and audit records
Show who can reach the tracing UI and APIs, which roles they hold, and how accounts are created and removed inside the enclosure. Phoenix supports OAuth2, LDAP and local accounts with role-based permissions. Langfuse project-level RBAC, audit logs and SCIM are behind an enterprise license key. Keep the access review results and the audit log exports, and confirm that the logs are stored inside the enclosure and retained for the period your policy sets.
Backup and restore test records
Backups of trace data, prompts and evaluation results are only evidence if a restore has been performed. Record the backup schedule, the storage location, the encryption method and the checksum of each backup. Then record a restore into a separate environment, the time it took, and the checks run afterward, such as trace counts and a sample prompt version. Remember that ClickHouse, PostgreSQL and object storage each need their own backup, and a restore must bring them back to a consistent state.
Offline upgrade records
Each upgrade inside an air-gapped network needs a record of the source release, the target release, the artifacts imported, the migration steps and the rollback plan. Langfuse applies database migrations at startup for updates within a major version, and major upgrades follow separate migration guides with their own prerequisites. Keep the pre-upgrade backup reference, the test run in staging, the approval and the post-upgrade verification. Ask your platform owner to confirm each release's offline procedure before importing it.
How DeployOpen scopes an air-gapped tracing deployment
DeployOpen scopes every air-gapped tracing deployment as a fixed-scope engagement, which means the scope, deliverables and timeline are agreed in writing before any work starts. For an air-gapped network, the written scope has to settle the questions that decide whether the platform will run at all: which platform is chosen (Phoenix, Langfuse or Opik), which Kubernetes distribution and storage classes exist inside the enclave, how container images and Helm charts reach the network, and which evaluator models will run locally. Ask for the scope to name each of these items and the person on your side who signs off on them. Timelines follow from that document, so an open question in the scope is a delay you will pay for later.
Inside your network, the deliverables typically cover the platform install, the supporting stores the chosen tool depends on, identity integration with your directory, hardening against your baseline, and documentation for backup and offline upgrades. For Langfuse, that means PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage inside the enclave. For Phoenix, confirm whether a PostgreSQL-backed deployment is in scope or whether SQLite is acceptable for your volumes. Ask for the offline upgrade runbook to be tested on a copy of the environment, including image transfer, database migrations and rollback. Backup scope should state which stores are captured, how often, where copies are kept and how a restore is proven. Retainers can cover ongoing support, upgrades and continuous testing after handover. Quotes follow from the written scope. DeployOpen does not publish prices, so ask for a quote that itemizes each deliverable and separates one-time setup from any recurring retainer.
How DeployOpen deploys open-source tracing inside closed networks
DeployOpen plans, builds, documents and supports self-hosted open-source tracing and evaluation inside the client's own air-gapped network. Each engagement starts with a written scope that fixes the platform choice, the offline image path and the handover deliverables before any work begins.
How we scope
- Inventory the networks, Kubernetes clusters and storage where traces and prompts will live
- Decide between Arize AX self-hosted, Phoenix, Langfuse or Opik against your licensing and feature needs
- Agree in writing how evaluator models, container images and upgrades reach the closed network
How we build
- Deploy the chosen platform with its documented Kubernetes or Helm path inside your environment
- Mirror and verify every container image and chart through your approved transfer process
- Configure authentication, storage sizing, backups and instrumentation for your applications
How we hand over
- Document the architecture, offline upgrade steps, license key handling and recovery procedures
- Provide test evidence and configuration records that your auditors and security team can review
- Walk your platform and security staff through operations so the system runs without us
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Plan each offline upgrade cycle with your change board and rehearse it in a staging network
- Keep compliance evidence current as the platform and its dependencies change over time
