/
Common Prerequisites for Kyvos Enterprise Deployment

Common Prerequisites for Kyvos Enterprise Deployment

This documentation is for Kyvos 2026.8.x. To view documentation for other Kyvos versions, click here.

This documentation is for Kyvos 2026.8.x. To view documentation for other Kyvos versions, click here.

✅ Enterprise: AWS, Azure, GCP, and On-Premises

1. Overview

This section covers the prerequisites applicable to Kyvos Enterprise deployments on AWS, Azure, GCP, and on-premises environments.

2. All Clouds

2.1. Operating System & Software

  • Verify your OS is supported for your Kyvos release version (see "Supported environments and applications" in the Release Notes for that release).

  • Install Python 3.6.8.

2.2 User Account & Permissions

  • Use a non-root user account for deployment.

  • This account needs read and write permissions on the installation path.

2.3 Disk Space

  • Ensure sufficient free disk space on all cluster nodes.

2.4 Required Ports & SSH Access

  • See the required ports for Kyvos.

  • Kyvos Manager is a distributed cluster lifecycle management tool and relies on SSH to manage cluster nodes:

    • SSH access to all cluster nodes is required for lifecycle activities: upgrades, patches, rollbacks, configuration/service management, and configuration syncing.

    • The scp command must be available (with execute permissions) on all cluster nodes, so Kyvos Manager can copy files — application bundles, patches, licenses — from the Manager node to cluster nodes.

2.5 Required OS Commands

  • Install all Required OS Commands (used by Kyvos Manager and Kyvos) on every cluster node.

  • (Optional) To enable TLS, install OpenSSL on the Kyvos Manager and Kyvos Analytical Server nodes:

    yum install openssl

2.6 Cloud IAM Roles

Required permissions must be attached to the deployment role for your cloud platform:

  • AWS — IAM permissions

  • Azure

  • GCP

(See platform-specific guides for exact permission lists.)

2.7 Kernel & Resource Limits

Configure the following kernel and resource limits on all Kyvos nodes, including the Analytical Server, Query Engine, and Kyvos Manager.

  1. Open the kernel parameter file to increase max map count: vi /proc/sys/vm/max_map_count

  2. Set the value to 524288.

  3. Run the following commands as the root user to increase the open-file limits for the kyvos user:

    echo kyvos hard nofile 524288 >> /etc/security/limits.conf echo kyvos hard nofile 524288 >> /etc/security/limits.d/20-nproc.conf echo kyvos soft nofile 524288 >> /etc/security/limits.conf echo kyvos soft nofile 524288 >> /etc/security/limits.d/20-nproc.conf

2.8 CPU & Memory

Configure Kyvos CPU and memory allocation based on the capacity of the selected VM instance to ensure optimal resource utilization. For example, for a node provisioned with 64 GB of RAM, allocate an appropriate amount of memory and CPU cores to Kyvos processes while reserving sufficient resources for the operating system and other required services.

2.9 System Resources

Node

Requirement

Node

Requirement

Analytical Server and Query Engine nodes

Minimum 32 GB RAM, 4 CPU cores

Kyvos Manager node

Minimum 200 GB available space in the installation directory

Query Engine nodes

Minimum 500 GB hard disk

For more details about system resources, see the Supported environments and applications section.

2.10 User Account

  • Create a non-sudo user account with common credentials across all nodes on which the Kyvos cluster will be installed. Use these credentials during Kyvos cluster installation.

  • If deploying the Kyvos cluster using password-based authentication for service nodes, ensure the required permissions are available on all VM instances for the Linux user deploying the cluster.

2.11 Required Directories

  • Create the following directories on all nodes:

    • /data/kyvos/app

    • /data/kyvos/install

  • Permissions: Set 750 permissions on these directories and make the Kyvos user the owner.

2.12 Required Packages

Package

Node(s)

Command

Package

Node(s)

Command

OpenSSL (enables TLS)

Kyvos Manager node

apt install openssl

zip

All nodes

apt install zip -y

fontconfig

All nodes

apt install fontconfig -y

2.13 Semantic Model Local Path

  • Create a directory for the Semantic Model local path on Query Engine nodes.

  • Set 750 permissions and make the Kyvos user the owner.

Example: /data1/kyvos/app/cube_local_cache

On this page:

Kyvos Enterprise Deployments:

3. Installing Prerequisites for Wizard Deployment using Kyvos Single Script

Kyvos provides one deployment script (PrereqScriptAllCloud.sh) that automatically installs all necessary prerequisites across AWS, GCP, and Azure. The script works with all instance types, including:

  • Analytical Server

  • Query Engine

  • Kyvos Manager

  • Kyvos Web Portal

3.1 Configuring the Deployment Script

Before running the script, open the file and define two categories of variables:

Variable Type

Description

Variable Type

Description

Common Variables

Apply to all cloud platforms. All common variables must be completed.

Cloud-Specific Variables

Apply only to your target platform (AWS, GCP, or Azure).

To configure the script, perform the following steps.

  1. For AWS, Azure, and GCP (N2 series), download the prerequisites deployment script.

  2. Configure the required variables:

    1. Open the script file and enter the required values.

    2. Ensure that all common variables are filled in.

    3. Provide the appropriate cloud-specific variables based on your deployment platform.

  3. Execute the script based on your cloud provider (AWS, Azure, and GCP).

    1. Create a new instance.

      1. For AWS: EC2 Instance

      2. For Azure: Virtual Machine

      3. For GCP: A new compute engine.

    2. SSH into the instance (AWS and GCP) or VM (Azure).

    3. Navigate to the /tmp/ directory and place the script file there (ensuring all variables are pre-configured).

    4. Run the following commands with root user:

      chmod 777 PrereqScriptAllCloud.sh ./PrereqScriptAllCloud.sh

3.2 Dedicated Compute Cluster

If you use dedicated compute cluster, see the Working with dedicated compute cluster section for all clouds.

3.3 Install PostgreSQL 16 for Wizard-Based Deployments

If your wizard-based deployment will use PostgreSQL 16 as an installed service, complete these manual steps before deployment.

  1. Step 1 — Install PostgreSQL 16

    1. Execute the script with root user.

    2. Manually install PostgreSQL 16 on the Kyvos Manager (KM) node.

    3. Execute the Kyvos-provided installation shell configure-postgres16.sh script.

  2. Step 2 — Update JDBC properties
    Before starting Kyvos Manager, update jdbc.properties to set: installedRepo=true

4. Kyvos Manager Installation for Wizard-Based Deployment

This section covers the software and hardware prerequisites for installing Kyvos Manager. It also covers the standard checks you must perform before starting the installation.

See the Kyvos Manager Installation Guide for more details.

5. On-Premises for No-Spark Kyvos Deployment

The same NFS (Network File System) must be mounted on every compute node in the cluster.

6. Single Node Standard (SNS)-Based Deployment

Machines must have at least 32 GB memory.

7. Existing Kubernetes (K8s) Cluster for AWS and Azure

7.1 Before Using an Existing K8s Cluster

  1. Shared clusters are not supported on AWS.

  2. On AWS, namespaces for the existing K8s cluster must use the fixed names kyvos-compute and kyvos-monitoring.

  3. On Azure, existing Kubernetes clusters are not supported for:

    • Fresh automated deployment

    • Fresh wizard-based deployment

    (They are supported only for configuring K8s in an existing external compute-based cluster.)

  4. The node pool of the Kubernetes cluster must be dedicated to Kyvos use.

  5. A single Kubernetes cluster can currently be used with only one Kyvos cluster — even if dedicated node pools are configured. In other words, you cannot assign one dedicated node pool of a K8s cluster to one Kyvos cluster and another dedicated node pool of the same K8s cluster to a different Kyvos cluster.

  6. The node pool used for Kyvos must use a single instance type. Node pools with multiple instance types are not supported.

  7. Each instance type in the node pool must meet a minimum requirement of 4 cores and 16 GB memory.

  8. Listing Kubernetes clusters and their node pools requires the appropriate permissions. Without these permissions, the relevant input field falls back to a text field instead of a dropdown.

7.2 Details for Using an Existing K8s Cluster with Kyvos

  1. The Kubernetes cluster name can be arbitrary — there is no requirement to use a fixed name.

  2. The node pool name can also be arbitrary, so a user-provided pool can be used with Kyvos.

  3. It does not matter how the pre-existing Kubernetes cluster was created (UI, ARM, or CFT) — it can still be used with Kyvos.

  4. The role or identity used to create the Kubernetes cluster can be the same as, or different from, the one used to create Kyvos resources. As long as the Kyvos role has the required permissions to access the Kubernetes cluster, it will work correctly.

  5. If the Kubernetes cluster resides in a different VPC than Kyvos, VPC peering is required.

  6. The Kubernetes cluster's security group and subnet should generally match those of the Kyvos cluster. If they differ, the existing K8s cluster can still be used, provided the Kyvos cluster's security group is updated with the necessary port and subnet access permissions.

8. Subject Alternative Name (SAN)-Enabled TLS Certificates

From Kyvos release 2026.5 onwards, Kyvos Enterprise (cloud), SaaS, and Marketplace deployments running JRE 17 must use SAN-enabled TLS certificates.

The certificate's Subject Alternative Name (SAN) extension must include the IP addresses and/or hostnames of all Analytical Server, Web Portal, Query Engine, and Kyvos Manager nodes. Certificates missing required SAN entries are not supported — validate and update certificates before upgrading.

Platform

Deployment Type

TLS (Yes/No)

JRE Version

SAN Enabled TLS Certificates (Yes/No)

Platform

Deployment Type

TLS (Yes/No)

JRE Version

SAN Enabled TLS Certificates (Yes/No)

Clouds Enterprise (AWS, Azure, and GCP)

No-Spark

Yes

17

Yes

On premises

No-Spark

Yes

8

No

Marketplace (AWS, Azure, and GCP)

No-Spark

Yes

17

Yes

SaaS (AWS, Azure, and GCP)

No-Spark

Yes

17

Yes

Note

  • This is not applicable to on-premises or any cloud environment running with Java8 setup.

  • When adding a node from Kyvos Manager, the TLS certificate must contain SAN entries for the IP addresses and/or hostnames of all Analytical Server, Web Portal, Query Engine, and Kyvos Manager nodes.

  • Post Disaster Recovery (DR), new SAN-enabled TLS certificates must be generated and configured.

To validate that a certificate contains the required Subject Alternative Name (SAN) entries, run the following command:

  1. Open a terminal on the system where OpenSSL is installed.

  2. Run one of the following commands based on your deployment type:

    • For existing TLS-enabled deployments:

      openssl s_client -connect SERVER.DOMAIN.COM:PORT -servername DOMAIN.COM </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

    • For new deployments:

      openssl x509 -in certificate.crt -noout -ext subjectAltName

  3. Review the command output and verify that the Subject Alternative Name (SAN) extension contains all required DNS names and/or IP addresses for the deployment.

    Example:

    DNS:kyvosinsights.zendesk.com or IPs or Both

  4. Ensure that the SAN extension includes the hostnames and IP addresses of all applicable Analytical Server, Web Portal, Query Engine, Compute Master (for Azure Kubernetes-based deployments with compute master only), and Kyvos Manager nodes.

  5. If any required DNS names or IP addresses are missing, update and reissue the certificate before proceeding with the deployment or upgrade.

Copyright Kyvos, Inc. 2026. All rights reserved.