Air-Gapped Deployment

The core Telovix workflow can operate without internet access after artifacts and a signed license cross the boundary. Sensors communicate only with the internal Console. Optional services such as external email, webhooks, SIEM destinations, AI providers, and online update checks require whichever network access those destinations use.

Plan the boundary

Before installation, identify:

• an internal Console hostname or IP reachable from every Sensor;
• internal PostgreSQL and ClickHouse services;
• an approved transfer process for binaries and license files;
• an operator workstation that can open the internal Console;
• internal DNS and time synchronization;
• a license renewal and update-transfer owner.

Size the complete internal stack using Requirements. Air-gapped operation does not reduce ClickHouse storage or cleanup headroom requirements.

Required artifacts

Transfer and verify:

Artifact	Source	Purpose
Console binary for the target architecture	Portal Downloads	Runs the complete Console web application
Signed license bundle	Portal deployment	Activates the specific Console ID

The Console binary includes supported Sensor binaries and the local SBOM scanner. Separate Sensor downloads are needed only when Telovix supplies an updated Sensor package independently or your operating process requires explicit staging.

Verify the Portal SHA-256 value before and after transfer.

License binding in an isolated environment

A self-hosted license is bound to the Console ID shown on first run. Choose one approved process:

1. Launch the Console inside the protected environment, copy the displayed Console ID through the approved outbound process, register it in Portal, then transfer the issued license bundle back in.
2. Coordinate a pre-registration workflow with Telovix before closing the environment.

Do not create a second Console instance merely to obtain an ID. The license must match the instance that will operate inside the boundary.

License verification occurs locally. Once the correct signed bundle is imported, normal validation does not require Portal connectivity.

Install Console

1. Transfer the verified Console binary to persistent internal storage.
2. Launch it as described in Console Installation.
3. Open the internal Console URL.
4. Register the displayed Console ID and import the returned license through the approved transfer process.
5. Configure internal PostgreSQL and ClickHouse endpoints.
6. Choose Standard or Telecom and create the first Admin.

The Console generates local Sensor trust material automatically. If your organization requires an internal PKI, configure that approved certificate process before enrolling production Sensors.

Enroll Sensors

Sensor hosts need access only to the internal Console address. From the Console:

1. Open Sensors > Deploy.
2. Select the deployment type.
3. Generate the command or Helm instructions.
4. Run them within the protected environment.
5. Confirm each Sensor is healthy in Fleet.

The installer obtains its Sensor package and trust bootstrap from the Console. It does not need internet access.

For Kubernetes, make the Helm chart available through an approved internal chart repository or transfer the chart package into the environment before installation.

Offline updates

Do not use an online update check in a fully isolated environment.

For a Console update:

1. Download and verify the approved Console release outside the boundary.
2. Transfer it through the same controlled process.
3. Back up Console operational data.
4. Stop the service manager.
5. Replace the executable while preserving its working directory and telovix-data.
6. Start Console and verify healthz, readyz, and sign-in.

For Sensor updates:

• upload approved Sensor binaries through the Console when a separate package is supplied;
• use a canary managed plan for VM and bare-metal Sensors;
• update the Helm image tag for Kubernetes;
• update launch templates for ephemeral hosts.

Never transfer a new package directly to every Sensor when the Console-managed workflow is available.

Renewal

Track the license expiry shown in Console. Before expiry:

1. issue the renewed bundle for the same deployment and Console ID;
2. transfer it through the approved process;
3. import it in Console;
4. verify the new validity period.

Document enough lead time for approval and transfer. Do not rely on the grace period as the normal renewal window.

Validation checklist

• [ ] Console binary checksum verified on both sides of the boundary
• [ ] Console ID registered and matching license imported
• [ ] PostgreSQL and ClickHouse use persistent storage
• [ ] Internal DNS and time synchronization work
• [ ] Operator browser trusts the approved Console endpoint
• [ ] Sensor command downloads only from the internal Console
• [ ] One VM or bare-metal Sensor enrolls successfully
• [ ] One Kubernetes cluster enrolls successfully, when applicable
• [ ] External integrations are disabled or point to approved internal services
• [ ] Offline update and license-renewal procedures are tested

Troubleshooting

Symptom	Check
License mismatch	Confirm the bundle was issued for the Console ID shown by this instance.
Sensor install tries the wrong hostname	Use the generated command for the stable internal Console address.
Sensor package is unavailable	Verify the Console data directory is writable and the selected architecture and flavor are supported.
Kubernetes cannot add the public chart repository	Mirror or transfer the chart through the approved artifact process.
Online integration remains failed	Point it to an internal service or disable it for the isolated deployment.

Further reading

• Console Installation
• Enrollment Tokens
• Upgrading Sensors
• License Validation