Why LangSmith is hard to run in an air-gapped network
If you run LLM tracing and evaluation on a disconnected network, the first question is whether the platform can operate with no outbound route at all. For self-hosted LangSmith, the answer depends on a license decision. Unless the instance runs in offline mode, it must reach beacon.langchain.com for license checks, and billing telemetry is required and cannot be turned off. Customers who need zero egress have to contact LangChain sales about an offline (air-gapped) license. Confirm that offline license in writing, including its terms and renewal process, before you plan the rest of the deployment, because an unplanned outbound dependency can stop a go-live in a regulated network.
The short answer is that Langfuse, Opik and Arize Phoenix can all run with no egress, and none of them requires a license key to do so for their core features. Phoenix's self-hosting documentation says traces, prompts and data stay in your infrastructure, including air-gapped deployments. Opik's README states the full platform, including tracing, evaluations and prompt management, can be self-hosted without a commercial license. Langfuse's core features are available under the MIT-licensed open source version without limits. Langfuse does gate some enterprise features behind a license key, such as project-level RBAC and audit logs, so confirm with your security team which of those controls you need and whether they must be on the open source tier or the enterprise tier.
Whatever you choose, verify the no-egress claim on your own network rather than relying on documentation alone. Block outbound traffic at the perimeter, deploy a trial instance, and watch for failed DNS lookups or connection attempts during startup, upgrades and normal tracing. Also plan for the parts that a disconnected network does not supply automatically: container images and Helm charts mirrored into your registry, model endpoints reachable from inside the enclave, and a process for bringing approved updates across the boundary.
What an air-gapped network requires from an LLM tracing platform
A disconnected network changes what a tracing platform may do at runtime, at install time and at upgrade time. The four requirements below connect licensing, packaging, model access and maintenance, and each one is a question to settle before a platform is chosen.
No outbound license or telemetry calls
Self-hosted LangSmith needs egress to beacon.langchain.com unless it runs in offline mode, and billing telemetry cannot be turned off. Going without any egress means contacting sales for an offline license. Ask whether the platform starts, traces and evaluates with no outbound connection at all, and confirm this in a test segment with the firewall closed before you commit. Open-source options with no license server avoid this dependency entirely.
Mirrored images and Helm charts
A disconnected cluster cannot pull from public registries, so every container image, Helm chart and database image must be copied into an internal registry first. Langfuse runs as two application containers, Web and Worker, alongside PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, so the mirror list is longer than the product name suggests. Build a manifest of every image tag your chosen version references and verify it against the chart's values before the transfer.
Model endpoints inside the network
Tracing platforms record prompts and completions, but the models that produce them must also be reachable from inside the enclosure. In practice this means an internally hosted model server or gateway, such as a self-hosted LiteLLM gateway, that the application calls and whose logs feed the tracing system. Confirm which model endpoints your applications use, that each resolves only on the internal network, and that the tracing SDK does not call a provider directly from outside.
Updates and migrations from an internal source
Langfuse applies database migrations automatically at startup for updates within a major version, so the internal mirror must hold each patch release before the cluster pulls it. Major upgrades follow separate migration guides, and the v3 to v4 path requires ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later. Plan a staged upgrade path inside the enclave, back up each database before the migration runs, and keep a rollback image available.
Offline docs and evidence retention
Air-gapped operators often cannot open vendor documentation, release notes or license pages from a browser on the network. Mirror the release notes, the license file for each component and the chosen version's installation guide into the internal documentation store, and record the exact versions in your change records. Phoenix states that traces, prompts and data stay in your infrastructure, including air-gapped deployments, which makes evidence collection simpler, but the licensing terms still need to be reviewed and filed.
Where self-hosted LangSmith meets the constraint and where it does not
Self-hosted LangSmith is an add-on to LangChain's Enterprise plan. It requires a license key and deploys to your own Kubernetes cluster with Helm charts, with Terraform also documented. Unless the instance runs in offline mode, the deployment must reach beacon.langchain.com, and billing telemetry is required and cannot be turned off. Your data stays on your infrastructure, but the platform still has a scheduled outbound dependency that your network team has to allow.
- Outbound HTTPS to beacon.langchain.com: the egress rule has to be approved, documented and monitored like any other external dependency.
- Billing telemetry: the telemetry cannot be disabled in this mode, so your security reviewers should expect it to appear in data flow diagrams.
- License key handling: the key is an Enterprise artifact, so the key rotation and storage process should sit inside your secrets management controls.
- Helm or Terraform deployment: the install path is well suited to clusters you already operate, and your platform team owns upgrades on that cluster.
- Proxy and allowlist testing: confirm the exact behavior of the instance behind your egress proxy in a test environment before production.
Before relying on this tab, confirm with LangChain in writing which hostnames and ports the current release contacts, and whether any internal mirror or proxy configuration is supported.
LangChain's self-hosting documentation says that customers who need to run without any egress must contact sales about an offline (air-gapped) license. Offline mode removes the requirement to reach the beacon endpoint, but it is not a configuration option you can switch on alone. It depends on a license that LangChain issues, so the commercial conversation comes before the architecture work. Plan for that dependency early, because a network design that assumes offline operation without the right license will fail at go-live.
- Commercial path: the offline license is obtained through LangChain sales, so the timeline depends on that process rather than on your deployment work.
- Egress verification: after installation, capture network flows to show that no outbound calls leave the disconnected segment.
- Mirrored images and charts: your team must move container images and Helm charts into an internal registry before installation, which adds a supply chain step.
- Updates by transfer: new releases arrive through your controlled transfer process, so patch cadence and change approval need explicit owners.
- Model access inside the network: LLM endpoints used by your applications also need internal routes, since the platform itself does not supply them.
Before procurement, ask LangChain whether the offline license covers your deployment model, what it says about updates and support in disconnected environments, and what evidence they expect from you when the instance is verified.
Most of the risk in this decision sits in details that the public documentation does not settle for every case. Treat the points below as a written checklist for the vendor conversation, and record the answers in your architecture decision record. A verbal assurance from a sales contact is not enough for a regulated environment, and your security and compliance leads will expect the answers in writing before they approve a design.
- Telemetry scope: ask exactly what billing telemetry contains and whether any usage data leaves the instance in offline mode.
- Release cadence and delivery: ask how offline customers receive releases, security fixes and database migrations.
- License terms: confirm the term, renewal conditions and what happens to the instance if the license lapses.
- Support boundaries: confirm which support channels work from a disconnected network and what remote access, if any, the vendor expects.
- Data residency and region: confirm that the self-hosted instance keeps all trace and prompt data inside your infrastructure.
If any answer is unclear, document it as an open risk and decide whether an offline-capable open-source alternative should be evaluated in parallel.
Some open-source platforms state that they run without an external license check or telemetry requirement, which changes the air-gap question from a commercial one to an engineering one. Phoenix documents that traces, prompts and data stay in your infrastructure, including air-gapped deployments, and that it has no feature limits or license fees for self-hosting. Opik's README states that the full platform can be self-hosted without a commercial license. Langfuse's core features are available in its MIT-licensed open source version without limits. Each still needs its own verification in your environment.
- Phoenix: free to self-host with no feature limitations, and it supports OAuth2, LDAP and local accounts with role-based permissions.
- Opik: Apache-2.0 licensed, with Docker Compose for local use and Helm charts for production.
- Langfuse: core features are MIT licensed, but some enterprise features such as SCIM and audit logs need a license key.
- Mirroring and dependencies: every option still pulls images and backing services such as ClickHouse, PostgreSQL or Redis, so the mirror plan covers all of them.
- Licensing caveat: Phoenix is under the Elastic License 2.0, which is source-available rather than OSI open source, so check its terms before standardizing on it.
Before adopting any option, test its network behavior with egress blocked and confirm that installation, startup and tracing all succeed.
Which open-source platforms run with no egress
This table compares Langfuse, Opik, Phoenix, LiteLLM and Portkey's AI Gateway on whether they can run with no outbound calls, which data stores they need, and where licensing limits apply. Read each row against your own egress policy, and treat any gap as a question to confirm with the vendor before you commit.
| Requirement | Langfuse | Opik | Phoenix |
|---|---|---|---|
| Runs with no egress by design | Self-hosts in your VPC with no required call to a vendor service for core features; confirm your deployment has no telemetry or license callbacks enabled | Self-hosts fully without a commercial license; confirm the Docker Compose or Helm install has no outbound calls in your environment | Docs state Phoenix runs in air-gapped deployments with traces, prompts and data staying in your infrastructure |
| Stores you must provide | PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage, all inside your network | ClickHouse, MySQL and Redis, all inside your network | SQLite by default; PostgreSQL optional through PHOENIX_SQL_DATABASE_URL |
| Licensing limit for this use | Core features are MIT; features in ee directories and some items such as RBAC, audit logs and SCIM need an enterprise license key | Apache-2.0 for the full platform, including evaluations and prompt management, with no key required | Elastic License 2.0 with no feature limits; it is source-available, not OSI open source, and bars offering it as a hosted service |
| Access control in a disconnected network | SSO, RBAC and audit logs depend on edition; confirm which controls your assessor expects before rollout | Confirm SSO and role controls against your identity provider needs in the release you install | OAuth2, LDAP and local accounts with role-based permissions |
| Main trade-off | Broad feature set and strong data model, but a ClickHouse and PostgreSQL stack to operate and upgrade | Simplest path to a fully open license, but a smaller ecosystem for add-on controls than larger projects | Lightest footprint for a single team, but the license limits service offerings and key functionality |
| LiteLLM as gateway (self-hosted) | Logs to Langfuse, so it fits a no-egress stack if LiteLLM runs on your own hosts and model endpoints are internal | LiteLLM supports logging to other tools; confirm the callback you use does not call external services | Logging path to Phoenix uses OpenTelemetry; confirm the collector endpoint stays internal |
| Portkey AI Gateway | Fails the constraint in hybrid mode because the gateway calls control.portkey.ai over HTTPS | Not applicable as a control plane; use only the fully self-run gateway | Fails the constraint in hybrid mode; use only the self-run gateway, which is MIT licensed, with enterprise features excluded |
How to deploy Langfuse or Opik with no egress
This sequence takes a Langfuse or Opik deployment from licence confirmation to a running, internally upgradable instance that makes no calls to external endpoints. The result is a tracing and evaluation stack whose images, data, model calls and update path all stay inside your network.
Confirm licence and egress position per platform
The platform owner and the security lead confirm which features the team needs and whether any of them sit behind an enterprise key. Opik's README states the full platform can be self-hosted without a commercial license. Langfuse's core features are MIT licensed, but project-level RBAC, audit logs, data masking and SCIM need an enterprise license key. Record the decision in the architecture file. It is done when every feature the team relies on is mapped to either an open-source component or a licence key request, and the egress position is written down for each platform.
Mirror container images and Helm charts internally
The platform team pulls the Langfuse or Opik container images, the Helm charts and the chart dependencies on a connected staging host, scans them, and pushes them to your internal registry such as Harbor. Pin every image to an explicit tag or digest rather than a floating tag, and record the chart versions in your configuration repository. Opik's current release, 2.2.103, was published on October 16, 2026, so confirm the tag you intend to mirror against the Opik releases page. It is done when the cluster can pull every image and chart from the internal registry with no external registry configured.
Stand up the data stores inside the boundary
Provision PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage inside the network, using an internal object store such as Ceph RADOS Gateway, SeaweedFS or Garage where your standards require it. For Langfuse, the 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 instead. Size the trace retention and ClickHouse disk with the team's expected volume. It is done when each store accepts connections from the application namespace and nothing else.
Configure the platform to avoid external endpoints
The platform engineer sets the environment variables and Helm values so every store, the blob bucket and the SMTP or SSO endpoints point to internal addresses, and disables any telemetry, update checks or external asset loading your version exposes. Confirm each option against the official self-hosting documentation for your release, because flag names change between versions. Enforce deny-by-default egress with a network policy, then test with a short-lived pod that attempts outbound connections. It is done when the test pod cannot reach any address outside the cluster and the platform starts, serves the UI and accepts a test trace.
Connect instrumentation and the internal model gateway
Point the application SDKs or OpenTelemetry exporters at the internal Langfuse or Opik endpoint, and route model calls through an internal gateway such as a self-hosted LiteLLM proxy or a model server reachable inside the network. LiteLLM can log to Langfuse, so the trace path stays inside the boundary. Use Langfuse's OpenTelemetry integration or Opik's native framework integrations as the instrumentation path. Confirm that no SDK defaults to a public host. It is done when a test request through the internal gateway appears as a trace, with the model call and the stored payload both recorded inside your network.
Set up an internal upgrade path
The platform team creates a repeatable path that moves each release from a connected staging environment through mirroring, a test deployment and then production. Langfuse says updates within a major version are non-disruptive and run database migrations automatically at startup, while major upgrades follow separate migration guides. The 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 historic data. Take a backup before each upgrade and keep the previous image digest for rollback. It is done when a release has been rehearsed end to end on a copy of production data.
Choose Docker Compose for tests and Kubernetes for production
Use Docker Compose on a single virtual machine only for proofs of concept and functional tests, since Langfuse documents that setup as having no high availability. Production runs on Kubernetes with Helm, with Langfuse also documenting Terraform-based deployments on AWS, Azure and GCP. Opik likewise offers Docker Compose through its opik.sh script for local use and Helm charts for production. Keep the test environment on the same mirrored images so that results carry over. It is done when the production cluster runs from the Helm release and the Compose environment is kept for testing only.
Validate the air-gapped state before go-live
The security and compliance leads run a documented check on the production namespace. The check confirms that DNS and outbound traffic are blocked, that images come only from the internal registry, that the access model and audit configuration match the decisions made in step one, and that a restored backup returns the expected traces. Keep the output as evidence for your compliance team, who will decide what it proves. DeployOpen can prepare these controls and evidence, but independent auditors issue any assessment. It is done when the signed-off checklist is filed alongside the architecture record.
Keeping images, model access and updates current offline
Before a disconnected update cycle, decide how each platform's images and migrations reach the air-gapped side, because that process is what keeps a self-hosted tracing stack current. For Langfuse, the upgrade model is the most predictable: updates within a major version are documented as non-disruptive and apply database migrations automatically at startup, so the practical work is mirroring the image tags you pin and testing them in a staging enclosure first. Major upgrades are different. Each one (v1 to v2, v2 to v3, v3 to v4) has its own migration guide, and the Langfuse upgrade guide is the page to read before you schedule one. Plan the v3 to v4 move around its stated requirements: ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later, plus roughly 3x ClickHouse disk headroom if you backfill historic data into the observations-first model.
Model access is a separate dependency that many air-gapped designs forget. Traces and evaluations need an LLM for LLM-as-a-judge scoring, and that model must be reachable from inside the enclave. Route judge and application calls through an internal gateway such as a self-hosted LiteLLM proxy, which exposes one OpenAI-compatible endpoint and can point to locally served open-weight models. Confirm which provider keys are in scope, how virtual keys and budgets are issued offline, and whether the evaluators you rely on are configured against the internal endpoint rather than a public one. Test this path during a scheduled dry run, not during an incident.
Before you commit to a cycle, ask each vendor the questions their public documentation may not answer directly. For Opik and Phoenix, confirm how release tags are published, how far back the mirrored artifacts should be kept, and whether Helm charts and container images can be pulled from a private registry without external calls. For Langfuse, confirm the release notes and migration guide for each target version, and whether the Enterprise license key requires any validation traffic in your deployment mode. Record the tag, digest and checksum of every image you import, and keep a rollback path tested against a database snapshot. The vendor's release process, not the release calendar, should set how often your disconnected environment is refreshed.
Evidence to keep for an air-gapped tracing platform
A security or compliance reviewer will ask for proof that the platform works without egress, not just a diagram that says so. The six artifacts below cover what was tested, what was installed, what is licensed, who can access what, and whether data can be recovered. Keep them under change control so they match the running system on the day of review.
Egress test results
Record the outbound connection tests run from the tracing namespace or VLAN, including the date, the tester, and the destinations attempted. For LangSmith, the reviewer will expect to see that the instance does not reach beacon.langchain.com unless it runs under an offline license. For Langfuse, Opik and Phoenix, capture the same tests with the platform's telemetry and update checks disabled, and keep the firewall rule set that produced the result. Repeat the test after every upgrade, because a new image or chart can add a call-home.
Mirrored image inventory
List every container image, Helm chart and package the deployment pulls, with its exact version tag and digest, the internal registry path it was mirrored to, and the date it was copied. Include the database and cache images such as PostgreSQL, ClickHouse, Redis or Valkey, and MySQL where the platform uses it. An inventory without digests cannot prove that the running containers match the scanned ones, so generate it from the cluster rather than from a spreadsheet.
License position per component
Write down the license of each component and whether any feature in use sits behind a commercial key. Langfuse's MIT code excludes the ee directories, and self-hosted Langfuse features such as audit logs and SCIM need an Enterprise license key. Phoenix is under the Elastic License 2.0, which is source-available rather than OSI open source. Opik is Apache-2.0. Ask the vendor in writing to confirm the position for the exact version you deploy.
Access control configuration
Export the authentication settings, role assignments and the list of accounts with administrative rights. Phoenix supports OAuth2, LDAP and local accounts with role-based permissions, and Langfuse Enterprise adds project-level RBAC. Show how the directory in the disconnected network maps to platform roles, and how local break-glass accounts are stored and reviewed. Reviewers commonly ask who can view raw prompts and traces, so document that scope explicitly.
Backup and restore records
Keep dated records of backups for the relational database, the analytical store and the object bucket, along with the result of at least one full restore into a separate environment. Note where backup copies are kept inside the enclave and who holds the decryption keys. Phoenix's default SQLite file is simple to copy, but a production layout on PostgreSQL needs its own backup job. Restore tests matter more than backup logs.
Update and change records
Keep a log of each image import, chart version, migration and rollback in the disconnected network, with the approver and the egress re-test result attached. Langfuse applies database migrations automatically at startup within a major version, and major upgrades follow separate migration guides, so record which migration ran and when. Also record the source of each update file, since in an air-gapped setting every new release arrives through a controlled transfer.
Questions teams ask before an air-gapped LangSmith replacement
Does LangSmith offline mode remove the need to migrate?
Not always. Self-hosted LangSmith needs a license key, and its self-hosting docs say that unless the instance runs in offline mode, it must reach and billing telemetry is required and cannot be turned off. A fully disconnected network needs an offline (air-gapped) license, which the docs say you obtain by contacting sales. Before you renew, confirm with LangChain in writing that the license, the Enterprise plan and the offline mode all cover your network. The migration question then becomes a commercial one: whether the offline license fits your budget and roadmap compared with an Apache-2.0 or MIT option that has no license check at all.
What cost drivers apply to a self-hosted Langfuse or Opik deployment?
The software license is not the main line item for either option. You pay for infrastructure and the people who run it. Langfuse needs PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible storage, and Opik uses ClickHouse, MySQL and Redis. Costs rise with trace volume, retention length and the number of replicas for high availability. One-time costs include planning, integration and hardening. Recurring costs include compute, storage growth, upgrades and staff time. Ask any implementation partner for a quote built from a written scope that lists each component, the retention target and the expected ingestion volume.
What must our team provide before an air-gapped deployment starts?
You need a Kubernetes cluster or VM capacity inside the disconnected network, a private container registry that holds mirrored images, S3-compatible object storage, and the database services for your chosen platform. You also need an internal certificate authority, DNS, identity integration if you use SSO, and a way to move signed artifacts and updates across the boundary. Langfuse documents Docker Compose on a single VM for testing and Kubernetes with Helm for production. Confirm your own change control, approved transfer method and the model endpoints your applications will call before scoping the work.
Can our own engineers run an air-gapped Langfuse or Opik deployment without outside help?
Yes, if you have engineers who already operate Kubernetes, PostgreSQL, ClickHouse and object storage in production. Both platforms publish Helm-based production paths and documented resource minimums. The hard parts are usually not the first install. They are mirroring every image and chart, planning ClickHouse capacity for retention, and running upgrades that require migrations. Langfuse's major upgrades follow dedicated guides and the v3 to v4 path requires ClickHouse 25.12 or later. If your team lacks these skills, a fixed-scope engagement can cover planning, deployment, backup and documentation, with ongoing support available as a retainer.
How long does an air-gapped replacement take?
The supplied sources do not give a standard duration, and the answer depends on the factors you control. Duration grows with the number of environments, the size of historic trace data you backfill, the number of integrations to re-instrument, the approval steps for moving artifacts into the network, and how many evaluators and prompts you rebuild. Langfuse advises about 3x ClickHouse disk headroom when backfilling historic data during a v4 move, which is one planning input. Ask for a timeline that is tied to a written scope and a named list of deliverables before you commit to a date.
Does Phoenix's Elastic License 2.0 matter for internal use?
For purely internal use inside your own organization, the Elastic License 2.0 is usually less restrictive than teams expect, because its main limit is on offering the software to third parties as a hosted or managed service. It is still source-available rather than OSI-approved open source, and it forbids circumventing license key functionality. Phoenix's self-hosting docs describe it as free to self-host with no feature limits, and the docs say it works in air-gapped deployments. Have your legal team confirm the terms against how you plan to use and redistribute it, especially if you offer tracing to external customers.
How the engagement is scoped for disconnected networks
DeployOpen plans and deploys the self-hosted platform inside your own air-gapped network, whether that is Langfuse, Opik or Phoenix, and works from a fixed scope agreed in writing before any build starts. The scope names the platforms, the target environment, the number of clusters or hosts, the integrations to be built and the handover deliverables. Because most disconnected environments differ in their host images, registries and approval workflows, the first decision is which platform and deployment method fit the network you actually have, such as Docker Compose on a single VM for a pilot or Kubernetes with Helm for production. Before the statement of work is signed, ask for a written confirmation of the platform versions to be mirrored and the change process your security team will accept for them.
Your side of the engagement is the network design and the access that only you can provide. Expect to supply the segmentation plan, the internal DNS and certificate authority, a private container registry or artifact store that holds mirrored images and Helm charts, and a path for moving approved packages across the boundary. For the LLM layer, you supply the model endpoints your applications call, such as an internal gateway or self-hosted inference service, and confirm which provider keys, if any, may leave the enclave. Confirm also who owns the PostgreSQL, ClickHouse, Redis or Valkey and object storage services, since these are the components that carry trace data. Missing items in these areas are the most common cause of schedule slippage, so list them in the scope document with named owners.
DeployOpen prepares systems, configurations, runbooks and evidence that your own compliance assessors or auditors can review, including records of the egress tests, access controls and backup restores performed during the build. DeployOpen does not issue audit reports, attestations or certifications, and the scope should say so explicitly. Ask any compliance readiness work to be listed as a deliverable with the control areas it touches, and agree in writing who signs off each one. Also agree the acceptance criteria up front, including a check that the platform makes no outbound connections during normal operation, and what happens to changes requested after sign-off. Ongoing upgrades, mirrored-image refreshes and continuous testing can be contracted as a separate retainer, which keeps the one-time build and the recurring support visible as separate lines in the quote.
How DeployOpen deploys tracing under an air-gapped constraint
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source tracing inside your own infrastructure, including air-gapped networks. We start from the egress rules your network allows, then choose and deploy a platform that runs without reaching outside services.
How we scope
- Map every outbound path your network permits, and confirm in writing which endpoints stay blocked.
- Agree which platform, components, model endpoints and trace sources are in the fixed-scope deliverables.
- Confirm with your vendor whether any feature you need depends on an enterprise key or outside service.
How we build
- Mirror container images, Helm charts and dependencies into your internal registry before cluster installation.
- Deploy the chosen stack with its database, cache and blob storage inside your private network.
- Test that tracing, evaluations and prompt management work with egress blocked, and record the results.
How we hand over
- Deliver architecture, configuration and runbooks covering installs, backups and restores of stored traces.
- Document the offline update procedure, including how new images and migrations reach the disconnected network.
- Provide the control evidence your internal and external assessors need, without issuing any audit report or certification.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan major version upgrades with their migration guides, testing each one in a staging copy first.
- Re-verify the no-egress configuration after each upgrade or change to the network boundary.
