VCF Extension Network Insight: Deploying the GUI

Version: 2026.1.1.0

The VCF Extension Network Insight GUI is delivered as a Docker image. The same image runs with one command on a laptop and on a Kubernetes cluster, and its browser interface is the only interface that is used. This page covers getting it running; using it is described in the next section.

Prerequisites

• Docker (scenario a) or a Kubernetes cluster with an ingress controller and a storage class (scenario b).
• Network reach from the GUI to the systems it talks to: vCenter, NSX and Aria Operations for Networks on 443, and Aria Operations for Logs on 9543 (used later by the Management Pack for dropped-traffic monitoring). The full access table is in the next section.
• The image, pulled from registry.indevops.com/vcf-extension-microsegmentation/new-automation-gui:latest.
• An admin password of at least 12 characters for the interface.

Scenario (a): run locally with Docker

For a quick run on a single machine. Only Docker is required.

1. Install Docker Desktop (Windows or macOS) or Docker Engine (Linux), then confirm it works with docker version.

2. Choose an admin password of at least 12 characters. If none is set, the container generates a random password and prints it once in its logs.

3. Start the container:

   docker run -d --name microseg \
     -p 8443:8443 \
     -v microseg-data:/data \
     -e MSG_ADMIN_PASSWORD='choose-a-password-min-12-chars' \
     registry.indevops.com/vcf-extension-microsegmentation/new-automation-gui:latest
   

   -p 8443:8443 publishes the interface on https://localhost:8443. -v microseg-data:/data keeps settings, decisions and logs in a volume that survives a restart. -e MSG_ADMIN_PASSWORD=... sets the admin password.

4. Open https://localhost:8443 and log in as admin. The certificate is self-signed, so accept the browser warning on the first visit.

5. Continue with the first configuration in the next section.

6. Stop and start it later with docker stop microseg and docker start microseg; the volume is preserved.

Scenario (b): deploy on Kubernetes

For a team that deploys applications on Kubernetes.

Before the first deployment, create the namespace and the secret with the admin password; the vCenter, NSX and vRNI passwords are not needed here, because they are entered in the interface.

Then create the workload:

• a Deployment running the image on port 8443 (the GUI terminates TLS itself).
• a Service exposing port 8443.
• a PersistentVolumeClaim mounted at /data, so settings, decisions and logs survive pod restarts (5 GiB is a comfortable size).
• an Ingress routing to the Service over HTTPS (the backend speaks HTTPS, so the ingress must talk to it over HTTPS as well), with a valid certificate. The DNS record must point at the ingress controller address, not at a node address.

Three choices in the deployment are deliberate:

• One replica with a recreate strategy: the per-application lock and the memory of the plan live in the process, so a second replica would write to the same NSX policy twice.
• The GUI terminates TLS itself and the ingress talks to it over HTTPS, because it holds an account with write access to NSX and the session cookie keeps the Secure flag.
• Resources: an idle pod uses about 35 MiB; request around 100m CPU and 192 MiB, with limits near 1 CPU and 768 MiB to cover reading the inventory for a few hundred machines.

After the Deployment is ready, open the ingress host in a browser and log in as admin, then continue with the first configuration in the next section.