Air-gapped observability: how to run it and how to prove it

What silently depends on the internet

Many products described as on-premise still reach outward in ways that only appear when the route is cut. If you are assessing any tool for an isolated network, this is the list to work through:

Wrentrix's position on the first four is direct: it works fully air-gapped, with no license calls, no telemetry and no external model. 0 bytes of telemetry leave the network. The test is simple, so please don't take our word for it. See the verification section below.

Bringing the software across

Your exact process depends on your data transfer rules. The general shape is the same for most closed environments.

1. Assemble the bundle on a connected machine

Collect the chart, container images, agent files and, if you want AI, the model. Record what you collected, along with versions and checksums.

sha256sum wrentrix.tgz > SHA256SUMS
sha256sum -c SHA256SUMS

Run that second command again on the inside, after the transfer, to confirm nothing changed in transit.

2. Move it through your approved path

Whichever process you use (data diode, scanned removable media, a transfer station), plan time for the scan and approval steps. A large image set may take a while. Include this lead time in your upgrade schedule, because it can be the longest step.

3. Load images into your internal registry

Your platform team probably already has a process for this. On OpenShift, a disconnected cluster normally has a mirror registry and image mirror configuration already in place. Point the chart's values at your internal registry according to the values file that ships with your release.

4. Install

A Helm chart from a local file doesn't need to reach a chart repository:

helm install wrentrix ./wrentrix.tgz -n wrentrix --create-namespace -f values.yaml

Helm itself is only a client in this step, and needs only your cluster's API server. Installing Helm charts in an air-gapped cluster walks through the common traps, including charts that reference images by tag in places your values can't override and subcharts that expect outside repositories.

OpenShift users may prefer the OpenShift operator route, and small single-host environments can use Docker Compose.

5. Connect agents

Add a cluster or host in the UI, then download the YAML or install script with its token inside. For closed networks, an image-less agent install exists. Tell us about your registry rules, and we can go through how it applies to your setup.

AI in a closed network

AI is optional. If you want it, it runs on your own hardware with no external calls, and it can be turned off entirely.

A model is a file from outside your boundary, so treat it as you would any other imported artifact: scan it, record its digest and approve it through your normal process. What the AI does once it's in place is described under root-cause analysis. Write to us for what this involves in your environment.

Verifying that nothing leaves

Test this. Don't rely on our statement. There are two layers worth checking.

At the network boundary. Deploy in an environment where outbound traffic is denied and logged. Run the platform for a few days with agents connected, then look through the firewall's deny log for any attempt from Wrentrix components. Attempts matter too: software that tries and fails is telling you something, even when no data got out.

At the namespace. Kubernetes NetworkPolicy lets you express the same rule closer to the workload, assuming your CNI enforces it. This example allows egress only to pods in the cluster and to one internal range, and you should adjust it for your database, identity provider and model server:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-egress
  namespace: wrentrix
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector: {}
    - to:
        - ipBlock:
            cidr: 10.0.0.0/8

The 10.0.0.0/8 is a stand-in. Use the smallest internal range you can. Then run through this checklist with the policy active:

1. The UI loads fully, with no missing fonts or assets. Check the browser's network tab for outside requests.
2. A new cluster can be added, and nodes appear.
3. Traces and logs arrive and are queryable.
4. RCA, natural-language queries and "explain this screen" work, if AI is on.
5. The platform survives a full restart with no connection.
6. Leave it running past any period you are worried about, and see that nothing expires or changes.

The live demo is a hosted walkthrough with sample data, so it isn't part of this test. It's only for seeing the screens.

Things that are harder in a closed network

Being air-gapped has costs. These apply to any tool, and it's best to plan for them.

• Upgrades are a project. Every release has to pass through the transfer process. Keep a staging environment inside the boundary, because you can't look something up quickly once you've hit a problem. Decide how often you can realistically update, and how security patches get an expedited path.
• Support is harder. A vendor engineer can't connect. You will send sanitised logs out, through the same approved process, or you will have people on-site. Ask about this before signing, with any vendor. Talk to us about how this would work in your environment.
• Time sync. Traces, log timelines and change correlation all assume the same clock. Air-gapped networks sometimes have poor NTP. A clock skew of a few seconds between nodes can make a child span appear to begin before its parent. Fix your internal time source first.
• Internal certificates. Everything will use your internal CA, so agents, SDKs and browsers need to trust it. SDKs in different languages configure trust differently. OpenTelemetry defines OTEL_EXPORTER_OTLP_CERTIFICATE for a custom CA file, which is useful for this. Expiry monitoring for those internal certificates is covered under synthetic monitoring.
• No outside view. Synthetic checks from inside only see inside, which is usually what a closed network needs. Real-user monitoring works for users on the same network.
• Models age. A local model won't improve until you replace it. For operational tasks that lean on your own telemetry, that matters less than for general knowledge, but do treat model updates as a scheduled item.

Partly isolated networks

Many real environments are not fully air-gapped. They have a controlled proxy, a DMZ, a one-way export, or several segments. Some useful patterns:

• Place one Wrentrix installation in the most protected zone that needs it, and let other zones reach it through defined firewall rules.
• Collectors in each zone give you a single, documented point for each cross-zone flow.
• Multiple segments that must never be joined may need separate installations. Discuss how you would like to view them, because that's a design decision with a security dimension.

Access control applies inside the boundary as well, as an air gap doesn't protect you from insiders. See security and access control for LDAP sync, scoped views and the audit log.

Frequently asked questions

Can APM work in an air-gapped environment?

Yes, provided all of its components run inside the boundary and nothing depends on an outside service. Wrentrix works fully air-gapped, with no license calls, no telemetry and no external model. Test this yourself by running it where outbound traffic is denied and logged.

Does Wrentrix need internet access for licensing?

No. There are no license calls. Questions about how licensing and renewal work commercially in a closed network are best asked directly, at info@wrentrix.com.

How do AI features work without internet?

The model runs on your own hardware, so inference involves no external call. AI can also be turned off entirely.

What is an image-less agent install?

It's an agent installation option intended for closed networks, where pulling container images can be a constraint. How it maps onto your own registry rules depends on your environment. Ask us to go through the details for your setup.

How do I upgrade software in an air-gapped cluster?

Bundle the new chart and images on a connected machine, record checksums, move them through your approved transfer path, then load them into your internal registry and upgrade from there. Test in a staging environment inside the boundary first. Schedule enough time for scanning and approvals, since that's often the slowest step.