CERT+
Automate certificate lifecycle management including issuance, discovery, renewal, and deployment, across public and private trust CAs. Assess, prioritize, and plan your migration to quantum-safe encryption with the Quantum Trust Hub add-on module.
PKI+
Provision, govern and scale private trust certificates with a Post Quantum ready cloud based Enterprise PKI-as-a-Service.
SIGN+
Secure software, firmware, and containers with a comprehensive enterprise code signing solution.
SSH+
Control SSH access and key rotation at scale with an SSH key lifecycle management solution.
KUBE+
Unify DevOps and Security teams by managing certificates with a Kubernetes-native certificate lifecycle management solution.
DDI+
Manage domain registration, renewal, decommissioning, and other security controls with an end-to-end domain lifecycle management solution.
ADC+
Automate and orchestrate application delivery infrastructure at scale with an ADC lifecycle automation platform.
Platform
Manage policy and automation across all of the products and modules in the AVX ONE platform.
AppViewX Setup
Get detailed instructions for setting up AVX ONE in on-premises or SaaS deployments.
Release Artifacts
Review new features, fixes, and security advisories with official AppViewX release documentation.

Steps to check pod status

Navigate to deps/tools/
Execute the command ./k3s kubectl get pods -n cc

Expected result:

There should be 2 pods avx-mid-server-starter and avx-mid-server-platform and both should be in running state.

Pod Description:

avx-mid-server-starter: Responsible for startup of the CC, this downloads the required artifacts from AppViewX servers to CC nodes during startup. Post successful startup, this pod does not play any significance. Restarting the pod would download the artifacts once again and upgrade to the latest cloud connector changes from the server.

avx-mid-server-platform: Responsible for all device communication, it checks with AppViewX SaaS servers, and if there are any actions that need to be performed and if it finds that actions have to be performed (for example Discovery, Device Addition, Certificate push, and so on), then the commands will be executed on the end device from this pod and response will be sent back to AppViewX servers.

AppViewX